On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle <timphardcas...@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.) > 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 > <https://groups.google.com/d/msgid/golang-nuts/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%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/CANrC0BgMG03iVChUjD7O876H1Yu7r2Vvcwm5TT6zCWYtyVJqWg%40mail.gmail.com.
