Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Poll Results: Which 'Elements of Programming Style' Are Totally Wrong? [125 responses]

DZone's Guide to

Poll Results: Which 'Elements of Programming Style' Are Totally Wrong? [125 responses]

Don't let anyone tell you there's nothing new under the programming sun. Sometimes even Brian Kernighan overdoes it. More insights to follow...

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

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?



Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:
research ,analysis ,poll ,progamming style

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}