Last week we asked what you thought of Kernighan and Plauger's classic Elements of Programming Style. 125 responded, which doesn't strongly represent the whole world's developer population (if the sample were totally randomly selected from all developers in the world (which it isn't), and if the one-question poll had only two answer options, then at a 95% confidence level the confidence interval would be a pretty big 9), but results are worth examining at least to understand our own community better.

Full results are embedded below and accessible here. Three points worth calling out at first pass:

1. Most {strongly|null} disagreed-with principle (45%): Write first in easy-to-understand pseudo language; then translate into whatever language you have to use. Maybe K&P proposed this in (pre-OO) 1974 because procedural code makes higher-level understanding difficult. Also unclear whether respondents took 'pseudo language' to include non-source symbol systems like UML (which also serve the 'get it before implementing it' goal) or just code read linearly by compiler/interpreter -- but guessing the 'pseudo' sounded enough like 'pseudo-code' not to mean boxes and arrows. 

2. Interesting 'most {strongly|null} disagreed-with' runner-up: Avoid too many temporary variables (22%). True, this is worse for DMA languages (rollin' a little calloc(), oops forgot to  free()) and less worrisome for memory-managed (we Java lovers might call them "high productivity") languages. Still can be readability issue (cognitive mismatch between human brain whose working memory doesn't exactly use named temp variables).

3. The top ten most {strongly|null} agreed-with principles, except one (the DRY one), are all about human readability and maintainability, not algorithmic efficiency and not even very specific to computation (Say what you mean, simply and directly./Choose variable names that won't be confused./Replace repetitive expressions by calls to common functions./If a logical expression is hard to understand, try transforming it./Write and test a big program in small pieces./Modularize. Use procedures and functions./Write clearly -- don't be too clever./Make it right before you make it faster./Use variable names that mean something.).

Will keep digging and let you know what else we find. Anything about these answers immediately strike you?