[chipsy]

I think the mentality can be extended to most code-reading. Don't get it by skimming? Must be crap code. I only got away from that when I changed my litmus test towards whether I could write on top of the codebase successfully, not how it looked. Today my only real point of judgment about the look of code is whether it's written in a style that increases average error rate.

w/r to Python in particular, it has a history of ending up with idioms that are "tricky" and not particularly more or less terse than other techniques, but are able to exploit the standard library functions to get a faster-running result.

This is, of course, at odds with the motto of "there should be only one (obvious) way to do it," so every experienced Python programmer has to internalize a small dictionary of idiomatic one-liners for these exceptional cases. (Fortunately, it's not that big. I can only think of three or four off the top of my head.)

[specialist]

style that increases average error rate

Errors per LOC is allegedly constant, across all languages.

I also consider the cost of change when designing things.

I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.

[aidenn0]

> Errors per LOC is allegedly constant, across all languages.

If this is true, then a more verbose style will have a higher error rate. (more LOC to do the same task -> more errors)

[jalopezp]

>>Errors per LOC is allegedly constant > then a more verbose style will have a higher error rate.

I think that's what he means.

[adventureloop]

> Errors per LOC is allegedly constant, across all languages.

This implies that more expressive languages(more expressions per line) are less prone to errors.

You conclusion would be correct if he had stated that error per expression was constant between languages.

[chii]

Don't confuse correlation with causation. It may not be that more lines is the cause, but that the method of thinking that some languages require you to think in is error prone, and it just so happens that such a language also needs more LoC.

[dlitz]

> Don't get it by skimming? Must be crap code.

Well, there is some truth to that. Anecdotally, most lines of code will be read many times before they are changed/discarded, and most of this reading will be skimming, where the reader is either: 1) trying to understand the structure of the code, or 2) trying to figure out where to make modifications.

Code that's hard to understand quickly (e.g. by skimming) is technical debt. I think a good litmus test would include not just the effect on error rate, but also the effect on the time it takes to understand the code and to make changes to it.