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.
