On Wed, Jan 20, 2021 at 2:27 PM Axel Wagner <axel.wagner...@googlemail.com> wrote:
> I think the general rule of thumb I find agreeable is "the length of an > identifier should be inversely correlated to the distance between its > declaration and its use". > I just realized that this is wrong. It should be correlated, not inversely correlated m( Don't know where the "inversely" came from. > Personally, I find code with shorter variable names easier to read (the > code structure stands out more), as long as I know what the identifiers are > - so I strive to keep them as short as possible, while still retaining > clarity of what they are. That leads to above rule of thumb. > > As type-parameters are always inherently local to the declaration they > appear in (and even a method needs to mention them in the receiver), I > think it can be argued that they have similar locality to function > parameters and should follow similar rules. > > Personally, that's what I intend to do. For example > * If I only use one type-parameter, it doesn't matter - `[T any]` is easy > to understand and reading `T` should be clear enough > * If I have multiple type-parameters and there is enough context to > distinguish them, I will use single-letter names - e.g. `[K comparable, V > any]` or `[E Edge, N Node]` seem clear. > * If there is not enough context, I will name them, for documentation > purposes - e.g. `[Edge, Node any]`. > > Personally, I intend to use upper-case names, because I am used to > consider lower-case names to be a signal that a type is not exported and > would find that confusing in documentation. > > I have always a hard time understanding signature because these one letter >> don't give me any context to catch on. (It work for K and V because they >> are common and containers are an easy concept to grasp) >> Perhaps in go the generic parameters will stay close enough to not be a >> problem, but my experience in Java show me it's really hard to understand a >> hierarchy of parametrized types and function across multiple files when >> they all use the same letters. >> And as letters have barely no meaning behind it, they generally evolve in >> non controlled way. Not in containers or map/reduce but in some controller >> where every now fancy functionality add its share of constraints it can >> become daunting. >> In that case, using one letter just hide the mess behind it. >> >> So while one letter work well for containers and map reduce, and that I >> would wish that generic is used in simple way I think it's to early to make >> a decision. >> Hopefully if the go community doesn't go full Java style with it's >> generic one letter could be okay. >> >> >> Le mercredi 20 janvier 2021 à 04:34:05 UTC+1, Ian Lance Taylor a écrit : >> >>> On Tue, Jan 19, 2021 at 6:33 PM Wojciech S. Czarnecki <oh...@fairbe.org> >>> wrote: >>> > >>> > I'd propose to amend specification so the type parameter identifiers >>> were of A-Z set, >>> > ie. single uppercase ascii letter. While it is a current convention, >>> it would be better >>> > to have this convention forced by compiler. First to have an >>> additional cue "generics here", >>> > second - to close an easy avenue to hide cloudy or malignant >>> constructs in the source. >>> > >>> > = induced by conversation spotted in other thread: >>> >>> Personally I think this role would be better played by some sort of >>> linter. Reasonable people can disagree as to the naming style to use >>> for type parameters. >>> >>> Ian >>> >>> >>> > > Carla Pfaff via golang-nuts" <golan...@googlegroups.com> wrote: >>> > >> m8il...@gmail.com wrote: >>> > > On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com >>> wrote: >>> > > >>> > > > Seems to me that most generics implementations use a capital >>> letter >>> > > > abstracted type syntax that I hate. >>> > > >>> > > This is just a convention and not part of the syntax, which means >>> it's >>> > > irrelevant to the discussion about the proposal. You can easily use >>> > > lowercase letters/identifiers: >>> https://go2goplay.golang.org/p/eWgJSLNTZw8 >>> > >>> > -- >>> > Wojciech S. Czarnecki >>> > << ^oo^ >> OHIR-RIPE >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> > To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/20210120033232.7492029f%40xmint. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/9060b24f-810b-451f-bba7-42079c73ca4en%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/9060b24f-810b-451f-bba7-42079c73ca4en%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHLOt8wneGX2LbjC0mS%2BE2XNs_528%3DCp1f3J4Hr9qy96Q%40mail.gmail.com.
