> 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 <rud...@gmail.com>
> 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.
