> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand.

https://github.com/fzipp/gocyclo

> * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does.

https://github.com/mgechev/revive

> Now is this going to buy you good architecture for free, of course not.

It's not architecture to tell people to comment on their functions.

Also FTR, people confuse cyclomatic complexity for automagically making code confusing to the weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.

▲

arbol 9 days ago | parent | next [-]

I can understand why else is sometimes not needed. JS linters will remove unnecessary else statements by default.

https://eslint.org/docs/latest/rules/no-else-return#rule-det...

But never using it is crazy.

	▲	awesome_dude 9 days ago \| parent [-]
		In a similar vein to how I just responded to the other person, maybe eventually we'll abstract `else` away so that it's use is hidden, and the abstraction ensures that it's only being used where we all collectively decide it can/should be used.

▲

jonahx 9 days ago | parent | prev [-]

> he weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.

Not weird at all:

https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...

▲

awesome_dude 9 days ago | parent [-]

Well, I found it weird - the else keyword has been a stalwart of programming for... several decades now.

Maybe one day we will abstract it away like the goto keyword (goto is a keyword in Go, and other languages still, but I have only seen it used in the wild once or twice in my 7 or 8 years of writing Go)

Goto is still used in almost every language, but it's abstracted away, hidden in loops, and conditionals (which Djikstra said was a perfectly acceptable use of goto), presumably to discourage its direct use to jump to arbitrary points in the code

	▲	jonahx 9 days ago \| parent [-]
		In a sense, all of these coding practices -- whether restricting goto to loops and conditionals, which has broad acceptance these days, or avoiding else to "keep the happy left", or anything else in a coding style guide -- are just doing one thing: restricting the language to a smaller subset of itself. And in general the primary benefit of such restriction is to reduce cognitive load. Scheme is easier than C++. The downside of such restriction is loss of expressiveness. Whether the net benefit is good depends on how these two things trade off. Experience and developer preference are inputs to that equation, which is why devs fight over coding guidelines. But I think it's helpful to boil it down in this way at a high level. The ideal is smaller language where the expressiveness you've cut away is only rarely useful, and often error-prone.