[go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rudolf Martincsek]

> 2) Long variable names.

Where I work (not in Go), writing comments is frowned upon. That includes 
"docblock" style comments. If a function needs to be documented, it means 
the implementation is too complex and must be broken apart to reduce 
cyclomatic or whatever perceived complexity. Also uncle bob told us that 
functions should never be longer than 2-3 lines of code, so it should be 
enough to look at the source code to see what it does. That's the general 
sentiment in my team.
Comments are considered sign of "un"clean code.

So we use long variable and function names to make the code self 
documenting. (Hint: it doesn't)
Points 3,4,5 have similar roots, because in dynamic languages it was a 
trend many years ago. (ie: hungarian notation)

On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:

> 1) Long functions that go on forever and contain long lambdas and 8 levels 
> of indentation.
>
> 2) Long variable names.
>
> 3) Variable names which include the type of the variable.
>
> 4) Packages whose name contain the word '/pkg/'
>
> 5) Repos which contain the prefix go-
>
> 6) Code where almost every line prefixed by `_, _ =`
> and the underscores won't go away when you wipe your screen
>
>
>

-- 
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/e31cbba4-4bda-4568-9f43-28985995d773n%40googlegroups.com.

[go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Tim Hardcastle]

Agree with Rudolf on point 2. Long meaningful variable/function names are 
good. Comments become obsolete, they become detached from their code, 
they're only used to explain the name of the variable once and then you're 
left with something than reads

// urn contains the userlist
fxn := rx (frn)

 Now that editors have autocomplete to make up for my meagre typing speed, 
you bet your ass I'm going to have [eg from current project] a local 
variable called lastTokenWasColon and a method called addWordsToParser. 
Because knowing exactly what they do when I need to modify or debug saves 
me so much time and trouble. (Perhaps this varies from person to person. If 
my memory is poorer than yours, it has more of an upside for me than for 
you.)

And is there a better solution to the problem in point 1 than to break the 
function down into lots of little functions *with meaningful names*? (If 
the names (and pieces) aren't meaningful you've only technically broken it 
down.)

On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:

> > 2) Long variable names.
>
> Where I work (not in Go), writing comments is frowned upon. That includes 
> "docblock" style comments. If a function needs to be documented, it means 
> the implementation is too complex and must be broken apart to reduce 
> cyclomatic or whatever perceived complexity. Also uncle bob told us that 
> functions should never be longer than 2-3 lines of code, so it should be 
> enough to look at the source code to see what it does. That's the general 
> sentiment in my team.
> Comments are considered sign of "un"clean code.
>
> So we use long variable and function names to make the code self 
> documenting. (Hint: it doesn't)
> Points 3,4,5 have similar roots, because in dynamic languages it was a 
> trend many years ago. (ie: hungarian notation)
>
> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>
>> 1) Long functions that go on forever and contain long lambdas and 8 
>> levels of indentation.
>>
>> 2) Long variable names.
>>
>> 3) Variable names which include the type of the variable.
>>
>> 4) Packages whose name contain the word '/pkg/'
>>
>> 5) Repos which contain the prefix go-
>>
>> 6) Code where almost every line prefixed by `_, _ =`
>> and the underscores won't go away when you wipe your screen
>>
>>
>>

-- 
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/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com.

[go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rudolf Martincsek]

> Agree with Rudolf on point 2.
Then you completely misunderstood my point. Because I said exactly the 
opposite. If your variable names are 10-15 words long (including 
prepositions) then you should document what the function does.

On Saturday, January 29, 2022 at 1:21:19 PM UTC+2 timphar...@gmail.com 
wrote:

> Agree with Rudolf on point 2. Long meaningful variable/function names are 
> good. Comments become obsolete, they become detached from their code, 
> they're only used to explain the name of the variable once and then you're 
> left with something than reads
>
> // urn contains the userlist
> fxn := rx (frn)
>
>  Now that editors have autocomplete to make up for my meagre typing speed, 
> you bet your ass I'm going to have [eg from current project] a local 
> variable called lastTokenWasColon and a method called addWordsToParser. 
> Because knowing exactly what they do when I need to modify or debug saves 
> me so much time and trouble. (Perhaps this varies from person to person. If 
> my memory is poorer than yours, it has more of an upside for me than for 
> you.)
>
> And is there a better solution to the problem in point 1 than to break the 
> function down into lots of little functions *with meaningful names*? (If 
> the names (and pieces) aren't meaningful you've only technically broken it 
> down.)
>
> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>
>> > 2) Long variable names.
>>
>> Where I work (not in Go), writing comments is frowned upon. That includes 
>> "docblock" style comments. If a function needs to be documented, it means 
>> the implementation is too complex and must be broken apart to reduce 
>> cyclomatic or whatever perceived complexity. Also uncle bob told us that 
>> functions should never be longer than 2-3 lines of code, so it should be 
>> enough to look at the source code to see what it does. That's the general 
>> sentiment in my team.
>> Comments are considered sign of "un"clean code.
>>
>> So we use long variable and function names to make the code self 
>> documenting. (Hint: it doesn't)
>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>> trend many years ago. (ie: hungarian notation)
>>
>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>
>>> 1) Long functions that go on forever and contain long lambdas and 8 
>>> levels of indentation.
>>>
>>> 2) Long variable names.
>>>
>>> 3) Variable names which include the type of the variable.
>>>
>>> 4) Packages whose name contain the word '/pkg/'
>>>
>>> 5) Repos which contain the prefix go-
>>>
>>> 6) Code where almost every line prefixed by `_, _ =`
>>> and the underscores won't go away when you wipe your screen
>>>
>>>
>>>

-- 
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/c253125b-bb18-42c8-86c0-021aacf0581an%40googlegroups.com.

[go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rick]

Really? The idea that functions should *never* be longer than 2-3 lines is 
absurd. Functions should take an input, do one thing (without side-effect) 
and return a result. And their name should indicate what function they 
compute. Whether that is 2-3 lines or 20-30 lines depends on the function.

On Friday, 28 January 2022 at 10:12:48 UTC-8 Rudolf Martincsek wrote:

> > 2) Long variable names.
>
> Where I work (not in Go), writing comments is frowned upon. That includes 
> "docblock" style comments. If a function needs to be documented, it means 
> the implementation is too complex and must be broken apart to reduce 
> cyclomatic or whatever perceived complexity. Also uncle bob told us that 
> functions should never be longer than 2-3 lines of code, so it should be 
> enough to look at the source code to see what it does. That's the general 
> sentiment in my team.
> Comments are considered sign of "un"clean code.
>
> So we use long variable and function names to make the code self 
> documenting. (Hint: it doesn't)
> Points 3,4,5 have similar roots, because in dynamic languages it was a 
> trend many years ago. (ie: hungarian notation)
>
> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>
>> 1) Long functions that go on forever and contain long lambdas and 8 
>> levels of indentation.
>>
>> 2) Long variable names.
>>
>> 3) Variable names which include the type of the variable.
>>
>> 4) Packages whose name contain the word '/pkg/'
>>
>> 5) Repos which contain the prefix go-
>>
>> 6) Code where almost every line prefixed by `_, _ =`
>> and the underscores won't go away when you wipe your screen
>>
>>
>>

-- 
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/4b77acfa-2d30-4d1f-8c4d-34a9c7aa6b40n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[David Finkel]

On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle 
wrote:

> Agree with Rudolf on point 2. Long meaningful variable/function names are
> good. Comments become obsolete, they become detached from their code,
> they're only used to explain the name of the variable once and then you're
> left with something than reads
>
> // urn contains the userlist
> fxn := rx (frn)
>
>  Now that editors have autocomplete to make up for my meagre typing speed,
> you bet your ass I'm going to have [eg from current project] a local
> variable called lastTokenWasColon and a method called addWordsToParser.
> Because knowing exactly what they do when I need to modify or debug saves
> me so much time and trouble. (Perhaps this varies from person to person. If
> my memory is poorer than yours, it has more of an upside for me than for
> you.)
>

There's a lot of middle-ground between a three-letter variable or
function-name and encoding the whole doc-comment for a function or variable
in its name.
Humans only have so much working memory, once a name gets long enough we
start dropping parts of the name and it tends to be stuff in the middle
that gets dropped.

If you have a parser type, and a variable with that type, often, it would
be better to have an addWords() method on the parser type. Then if you also
need a special-case addWord() it's easy to tell what's going on.

I try to have meaningful names, but beyond some threshold, but I try to
prevent things from being redundant with the types involved (the entire
function signature and type of the variable).

Also, comments are not about just describing what something is. (those are
the least useful types of comments) They're also quite useful for
describing what's being attempted, what corner-cases are being addressed
and if there's any tricky logic that needs to be handled. Additionally,
IMO, just about any function or method should have a doc-comment explaining
what it expects. (helpers under ~3 lines may be exempt)

>
> And is there a better solution to the problem in point 1 than to break the
> function down into lots of little functions *with meaningful names*? (If
> the names (and pieces) aren't meaningful you've only technically broken it
> down.)
>
> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>
>> > 2) Long variable names.
>>
>> Where I work (not in Go), writing comments is frowned upon. That includes
>> "docblock" style comments. If a function needs to be documented, it means
>> the implementation is too complex and must be broken apart to reduce
>> cyclomatic or whatever perceived complexity. Also uncle bob told us that
>> functions should never be longer than 2-3 lines of code, so it should be
>> enough to look at the source code to see what it does. That's the general
>> sentiment in my team.
>> Comments are considered sign of "un"clean code.
>>
>> So we use long variable and function names to make the code self
>> documenting. (Hint: it doesn't)
>> Points 3,4,5 have similar roots, because in dynamic languages it was a
>> trend many years ago. (ie: hungarian notation)
>>
>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>
>>> 1) Long functions that go on forever and contain long lambdas and 8
>>> levels of indentation.
>>>
>>> 2) Long variable names.
>>>
>>> 3) Variable names which include the type of the variable.
>>>
>>> 4) Packages whose name contain the word '/pkg/'
>>>
>>> 5) Repos which contain the prefix go-
>>>
>>> 6) Code where almost every line prefixed by `_, _ =`
>>> and the underscores won't go away when you wipe your screen
>>>
>>>
>>> --
> 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/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com
> 
> .
>

-- 
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/CANrC0BgMG03iVChUjD7O876H1Yu7r2Vvcwm5TT6zCWYtyVJqWg%40mail.gmail.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Henry]

Comments are useful to communicate what is not already apparent in your 
code. Sometimes comments may help you find bugs in your algorithms. On the 
other hand, keep your comments terse and not longer than what is necessary. 
Respect other people's time. 

Long names are not necessarily better. It is more important to have names 
that communicate your intent well and those names are not necessarily long. 
Any name that is longer than three words is usually too long.

As for long functions, my personal rule is that when you have more than one 
looping construct in a function, it is time to break it down. In Go, there 
is only one looping construct, which is the "for" keyword.

More importantly, know your "rules" and when to break them. They are not 
immutable. 

On Sunday, January 30, 2022 at 12:00:49 AM UTC+7 david@gmail.com wrote:

> On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle  
> wrote:
>
>> Agree with Rudolf on point 2. Long meaningful variable/function names are 
>> good. Comments become obsolete, they become detached from their code, 
>> they're only used to explain the name of the variable once and then you're 
>> left with something than reads
>>
>> // urn contains the userlist
>> fxn := rx (frn)
>>
>>  Now that editors have autocomplete to make up for my meagre typing 
>> speed, you bet your ass I'm going to have [eg from current project] a local 
>> variable called lastTokenWasColon and a method called addWordsToParser. 
>> Because knowing exactly what they do when I need to modify or debug saves 
>> me so much time and trouble. (Perhaps this varies from person to person. If 
>> my memory is poorer than yours, it has more of an upside for me than for 
>> you.)
>>
>
> There's a lot of middle-ground between a three-letter variable or 
> function-name and encoding the whole doc-comment for a function or variable 
> in its name.
> Humans only have so much working memory, once a name gets long enough we 
> start dropping parts of the name and it tends to be stuff in the middle 
> that gets dropped.
>
> If you have a parser type, and a variable with that type, often, it would 
> be better to have an addWords() method on the parser type. Then if you also 
> need a special-case addWord() it's easy to tell what's going on.
>
> I try to have meaningful names, but beyond some threshold, but I try to 
> prevent things from being redundant with the types involved (the entire 
> function signature and type of the variable).
>
> Also, comments are not about just describing what something is. (those are 
> the least useful types of comments) They're also quite useful for 
> describing what's being attempted, what corner-cases are being addressed 
> and if there's any tricky logic that needs to be handled. Additionally, 
> IMO, just about any function or method should have a doc-comment explaining 
> what it expects. (helpers under ~3 lines may be exempt)
>
>>
>> And is there a better solution to the problem in point 1 than to break 
>> the function down into lots of little functions *with meaningful names*? 
>> (If the names (and pieces) aren't meaningful you've only technically broken 
>> it down.)
>>
>> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>>
>>> > 2) Long variable names.
>>>
>>> Where I work (not in Go), writing comments is frowned upon. That 
>>> includes "docblock" style comments. If a function needs to be documented, 
>>> it means the implementation is too complex and must be broken apart to 
>>> reduce cyclomatic or whatever perceived complexity. Also uncle bob told us 
>>> that functions should never be longer than 2-3 lines of code, so it should 
>>> be enough to look at the source code to see what it does. That's the 
>>> general sentiment in my team.
>>> Comments are considered sign of "un"clean code.
>>>
>>> So we use long variable and function names to make the code self 
>>> documenting. (Hint: it doesn't)
>>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>>> trend many years ago. (ie: hungarian notation)
>>>
>>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>>
 1) Long functions that go on forever and contain long lambdas and 8 
 levels of indentation.

 2) Long variable names.

 3) Variable names which include the type of the variable.

 4) Packages whose name contain the word '/pkg/'

 5) Repos which contain the prefix go-

 6) Code where almost every line prefixed by `_, _ =`
 and the underscores won't go away when you wipe your screen


 -- 
>> 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/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com
>>  
>> 

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Brian Candler]

On Sunday, 30 January 2022 at 11:31:25 UTC Henry wrote:

> In Go, there is only one looping construct, which is the "for" keyword.
>

Don't forget "goto" :-)

<< ducks >>

-- 
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/f9180ffb-c3b2-4652-ae50-65420ba2e6b8n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Tim Hardcastle]

True, I don't say that meaningful names can entirely replace comments, just 
that comments can't replace the sort of meaningful if verbose names that OP 
objects to in point (1).

A lot must depend on the personal equation, how well one reads chunks of 
camelCase, how well one reads abbreviations, how good one's memory is, how 
fast one types, etc. Personally I find I just mess up less since I've 
learned to be more verbose.

On Saturday, January 29, 2022 at 9:00:49 AM UTC-8 david@gmail.com wrote:

> On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle  
> wrote:
>
>> Agree with Rudolf on point 2. Long meaningful variable/function names are 
>> good. Comments become obsolete, they become detached from their code, 
>> they're only used to explain the name of the variable once and then you're 
>> left with something than reads
>>
>> // urn contains the userlist
>> fxn := rx (frn)
>>
>>  Now that editors have autocomplete to make up for my meagre typing 
>> speed, you bet your ass I'm going to have [eg from current project] a local 
>> variable called lastTokenWasColon and a method called addWordsToParser. 
>> Because knowing exactly what they do when I need to modify or debug saves 
>> me so much time and trouble. (Perhaps this varies from person to person. If 
>> my memory is poorer than yours, it has more of an upside for me than for 
>> you.)
>>
>
> There's a lot of middle-ground between a three-letter variable or 
> function-name and encoding the whole doc-comment for a function or variable 
> in its name.
> Humans only have so much working memory, once a name gets long enough we 
> start dropping parts of the name and it tends to be stuff in the middle 
> that gets dropped.
>
> If you have a parser type, and a variable with that type, often, it would 
> be better to have an addWords() method on the parser type. Then if you also 
> need a special-case addWord() it's easy to tell what's going on.
>
> I try to have meaningful names, but beyond some threshold, but I try to 
> prevent things from being redundant with the types involved (the entire 
> function signature and type of the variable).
>
> Also, comments are not about just describing what something is. (those are 
> the least useful types of comments) They're also quite useful for 
> describing what's being attempted, what corner-cases are being addressed 
> and if there's any tricky logic that needs to be handled. Additionally, 
> IMO, just about any function or method should have a doc-comment explaining 
> what it expects. (helpers under ~3 lines may be exempt)
>
>>
>> And is there a better solution to the problem in point 1 than to break 
>> the function down into lots of little functions *with meaningful names*? 
>> (If the names (and pieces) aren't meaningful you've only technically broken 
>> it down.)
>>
>> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote:
>>
>>> > 2) Long variable names.
>>>
>>> Where I work (not in Go), writing comments is frowned upon. That 
>>> includes "docblock" style comments. If a function needs to be documented, 
>>> it means the implementation is too complex and must be broken apart to 
>>> reduce cyclomatic or whatever perceived complexity. Also uncle bob told us 
>>> that functions should never be longer than 2-3 lines of code, so it should 
>>> be enough to look at the source code to see what it does. That's the 
>>> general sentiment in my team.
>>> Comments are considered sign of "un"clean code.
>>>
>>> So we use long variable and function names to make the code self 
>>> documenting. (Hint: it doesn't)
>>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>>> trend many years ago. (ie: hungarian notation)
>>>
>>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>>
 1) Long functions that go on forever and contain long lambdas and 8 
 levels of indentation.

 2) Long variable names.

 3) Variable names which include the type of the variable.

 4) Packages whose name contain the word '/pkg/'

 5) Repos which contain the prefix go-

 6) Code where almost every line prefixed by `_, _ =`
 and the underscores won't go away when you wipe your screen


 -- 
>> 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/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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...@googleg

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Henry]

And there is that ... LOL. I normally ignore "goto", but yes it can be 
turned into a looping construct. When refactoring code that uses "goto", I 
would try to eliminate "goto" first. If it isn't possible, then the 
execution flow must be so complex that it doesn't need to be broken down 
further. 

On Sunday, January 30, 2022 at 9:24:15 PM UTC+7 Brian Candler wrote:

> On Sunday, 30 January 2022 at 11:31:25 UTC Henry wrote:
>
>> In Go, there is only one looping construct, which is the "for" keyword.
>>
>
> Don't forget "goto" :-)
>
> << ducks >>
>

-- 
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/108ce9eb-2378-4d78-a712-7986280cd710n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

['Thomas Bushnell BSG' via golang-nuts]

On Fri, Jan 28, 2022 at 1:12 PM Rudolf Martincsek  wrote:

> > 2) Long variable names.
>
> Where I work (not in Go), writing comments is frowned upon. That includes
> "docblock" style comments. If a function needs to be documented, it means
> the implementation is too complex and must be broken apart to reduce
> cyclomatic or whatever perceived complexity. Also uncle bob told us that
> functions should never be longer than 2-3 lines of code, so it should be
> enough to look at the source code to see what it does. That's the general
> sentiment in my team.
> Comments are considered sign of "un"clean code.
>

I agree with the sentiment.

So we use long variable and function names to make the code self
> documenting. (Hint: it doesn't)
> Points 3,4,5 have similar roots, because in dynamic languages it was a
> trend many years ago. (ie: hungarian notation)
>

If you use a long variable name for every variable then you haven't helped
anything. You need to use long variable names for some variables and not
others.

Using a short variable name gives the subtext "this variable is
boiler-plate or not very important". This is good for method receivers,
loop indexes, and so forth. Almost always a single word will do. For
example:

for _, otter := ListRiverOtters("europe")

Calling this variable "otter" is great. Calling it "europeanRiverOtter" is
absurd - that's already there, obviously in the code. (And if the loop is
fifty lines long, then the problem isn't that the reader has forgotten what
kind of otter it is - the problem is that a loop of fifty lines long is too
long.)

Exported function and method names should generally read "completely", but
even then, they shouldn't go repeating type names and all the rest. The
standard library, as always, is a great guide.

-- 
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/CA%2BYjuxuZe56ewuU7TjJj%3D4VS6YkyPeK1HE1wQdtsv3YJ4xiCfQ%40mail.gmail.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rudolf Martincsek]

> for _, otter := ListRiverOtters("europe")
> Calling this variable "otter" is great. Calling it "europeanRiverOtter" 
is absurd - that's already there, obviously in the code. 

Your "absurd" example is too charitable and naive. That's not even bad 
compared to what I encounter day by day. Some would write this as:

$europeanRiverOtters = 
$this->ottersFetcher->fetchOttersForContinent("europe");

But even this "worse" example pales in comparison to the actual code I have 
to deal with. To the tune of classes being called 
"DoSomethingForXAndYService" with methods like "getCountOfTotalX", 
"getAndSaveXInTable", "getXEligibleForY", "sortXByYAndZAndGroupByW" and so 
on. Where X, Y, Z, W are entity/model/domain_object/field names. I wish I 
could show examples, because you'll say that I'm exaggerating, but of 
course I can't.
And on top of this, english is not our mother language, but we write code 
in english. Reading the code becomes atrocious.


On Monday, January 31, 2022 at 11:34:47 PM UTC+2 Thomas Bushnell, BSG wrote:

> On Fri, Jan 28, 2022 at 1:12 PM Rudolf Martincsek  
> wrote:
>
>> > 2) Long variable names.
>>
>> Where I work (not in Go), writing comments is frowned upon. That includes 
>> "docblock" style comments. If a function needs to be documented, it means 
>> the implementation is too complex and must be broken apart to reduce 
>> cyclomatic or whatever perceived complexity. Also uncle bob told us that 
>> functions should never be longer than 2-3 lines of code, so it should be 
>> enough to look at the source code to see what it does. That's the general 
>> sentiment in my team.
>> Comments are considered sign of "un"clean code.
>>
>
> I agree with the sentiment.
>
> So we use long variable and function names to make the code self 
>> documenting. (Hint: it doesn't)
>> Points 3,4,5 have similar roots, because in dynamic languages it was a 
>> trend many years ago. (ie: hungarian notation)
>>
>
> If you use a long variable name for every variable then you haven't helped 
> anything. You need to use long variable names for some variables and not 
> others.
>
> Using a short variable name gives the subtext "this variable is 
> boiler-plate or not very important". This is good for method receivers, 
> loop indexes, and so forth. Almost always a single word will do. For 
> example:
>
> for _, otter := ListRiverOtters("europe")
>
> Calling this variable "otter" is great. Calling it "europeanRiverOtter" is 
> absurd - that's already there, obviously in the code. (And if the loop is 
> fifty lines long, then the problem isn't that the reader has forgotten what 
> kind of otter it is - the problem is that a loop of fifty lines long is too 
> long.)
>
> Exported function and method names should generally read "completely", but 
> even then, they shouldn't go repeating type names and all the rest. The 
> standard library, as always, is a great guide. 
>

-- 
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/f5d30e25-1dbe-4a56-beff-7e73ad4edc98n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Robert Engels]

If I hired on to a company that enforced 3-4 line function calls I would be 
looking for a job the next day. 

> On Jan 31, 2022, at 6:44 PM, Rick  wrote:
> 
> Really? The idea that functions should never be longer than 2-3 lines is 
> absurd. Functions should take an input, do one thing (without side-effect) 
> and return a result. And their name should indicate what function they 
> compute. Whether that is 2-3 lines or 20-30 lines depends on the function.
> 
>> On Friday, 28 January 2022 at 10:12:48 UTC-8 Rudolf Martincsek wrote:
>> > 2) Long variable names.
>> 
>> Where I work (not in Go), writing comments is frowned upon. That includes 
>> "docblock" style comments. If a function needs to be documented, it means 
>> the implementation is too complex and must be broken apart to reduce 
>> cyclomatic or whatever perceived complexity. Also uncle bob told us that 
>> functions should never be longer than 2-3 lines of code, so it should be 
>> enough to look at the source code to see what it does. That's the general 
>> sentiment in my team.
>> Comments are considered sign of "un"clean code.
>> 
>> So we use long variable and function names to make the code self 
>> documenting. (Hint: it doesn't)
>> Points 3,4,5 have similar roots, because in dynamic languages it was a trend 
>> many years ago. (ie: hungarian notation)
>> 
>>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote:
>>> 1) Long functions that go on forever and contain long lambdas and 8 levels 
>>> of indentation.
>>> 
>>> 2) Long variable names.
>>> 
>>> 3) Variable names which include the type of the variable.
>>> 
>>> 4) Packages whose name contain the word '/pkg/'
>>> 
>>> 5) Repos which contain the prefix go-
>>> 
>>> 6) Code where almost every line prefixed by `_, _ =`
>>> and the underscores won't go away when you wipe your screen
>>> 
>>> 
> 
> -- 
> 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/4b77acfa-2d30-4d1f-8c4d-34a9c7aa6b40n%40googlegroups.com.

-- 
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/B1592541-BBF1-4DE0-A33A-D09C75481D93%40ix.netcom.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Amnon]

Idiomatic naming in Go is one of the hardest things to communicate.
Everyone seems to bring the idioms from previous languages. Dave Cheney 
writes about 
"Lengthy bureaucratic names carry a low amount of signal compared to their 
weight on the page".
Identifiers are not sentences or stand alone stories. They are the the 
basic building blocks for our code.
We have all seen code infected by these names - long names leading to long 
lines of code,
and verbose walls of dense text, repetitive and hard to read.

I always encourage people to read https://go.dev/doc/effective_go#names
to study the Go standard library, and develop a feel of what Go code should 
read like.


>
>

-- 
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/2cd93f81-9ae1-4e49-890c-b2d383955febn%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rudolf Martincsek]

Latest interface my colleagues wrote (it's PHP)
---
interface UnreceivedMasterOrdersInterface
{
   public function getUnreceivedByProductsWarehouseAndCompany(array 
$productIds, int $warehouseId, int $companyId): array;
}
---
There is interest to switch to Go for some of the stuff we write, but I 
decided to leave before that happens. I like programming in Go for myself, 
and I don't want to start hating it because of nonsense like this.


On Wednesday, February 2, 2022 at 8:51:54 AM UTC+2 Amnon wrote:

> Idiomatic naming in Go is one of the hardest things to communicate.
> Everyone seems to bring the idioms from previous languages. Dave Cheney 
> writes about 
> "Lengthy bureaucratic names carry a low amount of signal compared to their 
> weight on the page".
> Identifiers are not sentences or stand alone stories. They are the the 
> basic building blocks for our code.
> We have all seen code infected by these names - long names leading to long 
> lines of code,
> and verbose walls of dense text, repetitive and hard to read.
>
> I always encourage people to read https://go.dev/doc/effective_go#names
> to study the Go standard library, and develop a feel of what Go code 
> should read like.
>
>
>>
>>

-- 
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/00dec58d-421a-4b86-9c15-6533fc648974n%40googlegroups.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Rob Pike]

It could have been

interface 
UnreceivedMasterOrdersInterfaceThatCanBeUsedToCallGetUnreceivedByProductsWarehouseAndCompany

Seriously, though, your example isn't even on the same planet as some
of the examples I've seen. (Neither is my parody.)

Sympathies.

-rob

On Tue, Mar 8, 2022 at 7:49 AM Rudolf Martincsek  wrote:
>
> Latest interface my colleagues wrote (it's PHP)
> ---
> interface UnreceivedMasterOrdersInterface
> {
>public function getUnreceivedByProductsWarehouseAndCompany(array 
> $productIds, int $warehouseId, int $companyId): array;
> }
> ---
> There is interest to switch to Go for some of the stuff we write, but I 
> decided to leave before that happens. I like programming in Go for myself, 
> and I don't want to start hating it because of nonsense like this.
>
>
> On Wednesday, February 2, 2022 at 8:51:54 AM UTC+2 Amnon wrote:
>>
>> Idiomatic naming in Go is one of the hardest things to communicate.
>> Everyone seems to bring the idioms from previous languages. Dave Cheney 
>> writes about
>> "Lengthy bureaucratic names carry a low amount of signal compared to their 
>> weight on the page".
>> Identifiers are not sentences or stand alone stories. They are the the basic 
>> building blocks for our code.
>> We have all seen code infected by these names - long names leading to long 
>> lines of code,
>> and verbose walls of dense text, repetitive and hard to read.
>>
>> I always encourage people to read https://go.dev/doc/effective_go#names
>> to study the Go standard library, and develop a feel of what Go code should 
>> read like.
>>
>>>
>>>
> --
> 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/00dec58d-421a-4b86-9c15-6533fc648974n%40googlegroups.com.

-- 
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/CAOXNBZQ9FvDDusTGkRZdJbUNOMCL%2B8Td2QW_7KYQK45CmEUfxA%40mail.gmail.com.