[jschwartzi]

Every discussion of code style eventually devolves to a discussion about readability, which eventually devolves to a knife fight in a conference room because one man's readable expression is another man's opaque one-liner.

[cookiecaper]

I think there's an objective way to resolve a good chunk of this, which is language exclusivity. If the code expresses an idea in a way that a programmer familiar with a similar language can understand without having to refer to the docs, it's great. If the code uses language-specific operators or functions, there needs to be a reasonable justification for it.

This basically means that these keywords and operations are always OK:

  * function definitions

  * if conditionals

  * full for loops

  * full while loops

  * return statements

and these things should only be used when it would be unreasonably intrusive or problematic to perform the same operation using only the above flow control mechanisms:

  * classes

  * lambdas/closures

  * language-specific shorthands like list comprehensions

  * language-specific operator aliases, like << for .append in Ruby

  * built-in functions that are likely to behave substantially differently from the intuitive expectation

The goal is to keep the program as simple and straightforward as possible. Of course you're going to need some of the things in the second category to do that sometimes. But my opinion is that one should start with the basic building blocks, and if one finds that it will save a lot of effort and time in both reading and writing the code to use one of the secondary things, only then should those things be deployed.

For example, if you're using a lambda, you should have a good explanation for why a function definition wouldn't have worked. "Lambdas take one line and defs take two" isn't a good reason.

[djur]

What about languages like Haskell that don't have for loops, while loops, or return statements? And anonymous functions exist in most languages and cannot be avoided in many of them.