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 <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.) >> > > 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 >> >> <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/b517c1bb-bef6-48d4-9258-c23f7009e992n%40googlegroups.com.
