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