EDIT: Long post warning.
Quite a discussion you guys have here!
Originally posted by: Markbnj
I'm not even sure how you would go about "coding for the weakest coder." If that means avoiding arcane or needlessly complex expressions where simpler or better understood ones will do, then I would agree with it in principle.
As others have pointed out, 'weakest coder' isn't a great notion to begin with. It would be better to not have a weakest coder at all -- to have all members of the team be gurus, Mels in every possibly way, and equally talented according to all possible measures.
However, since not all coders are Mel, I think coding-for-the-weakest-coder is a maintainability practice that advocates code that is simple and obvious.
Originally posted by: Cogman
It depends on what the weakest coder can do.
...
Moreover, the designated weakest coder is not a fixed notion. Its not always Jim, or Bob. Maybe Mel is having a bad day... everybody has idiot moments, and unexpected subtleties can crop up... well... unexpectedly. Defensive/obvious/simple code helps the 'stronger' coders, too, by not wasting their time figuring out what is going on (per more of Cogman's post, below).
The guy that maintains your code shouldn't have to read all the code to understand whats going on.
Indeed, hopefully not. I believe strongly in self-documenting code.
Originally posted by: DaveSimmons
Given that the person doing maintenance may not have looked at a function for a year or more, I see value in keeping the code as legible as is practical, avoiding clever or unusual coding as much as possible.
Agreed.
Originally posted by: KB
I have never heard of "coding for the weakest coder", but based on its description I would never advocate it. How will the weakest coder learn from the strongest, if all the code is written so the weakest would understand it. I have always coded for the strongest developer and the weaker ones then learn how to write better code by reviewing or updating the section of the code the stronger developer wrote.
I think we're actually talking about the same thing: writing solid, readable, maintainable, self-documenting, simple, straightforward, and useful code. In some sense, that is leadership by example for weaker coders.
--> The remaining comments are general, not really replies to anything in particular.
Keeping with the (bad) terminology we've used so far:
*Weak coders (WCs) are more likely to screw up code that is subtle than code that is straightforward.
*Strong coders (SCs) are also more likely to screw up code that is subtle than code that is straightforward, though SCs are less likely to screw up in general than WCs.
*In many coding environments, the SCs have a vested interest in converting WCs to SCs, though education. Doing so takes burden off the SCs, improves the code, and increases the value of the team/company/etc. (there is worry that WCs will replace SCs over time, however)
*One possible measure of coding quality is the length of time it would take an 85-year-old grandmother to understand it (ok, maybe granny goes too far with the analogy -- replace her with a first-year graduate student). There are few reasons to ever write code that requires an explanation beyond comments.
*Considerations from the style guide are important, but more important is the metapoint of the style guide: that code in a particular project/organization should look the same. The human brain is a pattern matching system -- code that looks the same is easier to understand once the brain gets the hang of the rules. For maintenance coding, this often means looking around at the code you're working on and adopting the style that is already here, even if it is different from Hoyle, or inferior to the style that the coder happens to prefer.
* Code reviews: Where to begin? Code reviews are as much a social consideration as a software engineering consideration. Its pretty easy for code review cliques to form, each of which adopts a particular variant of the company's style, and then stagnate (or even become malicious). However, this is at the heart of the point in this thread: all measures of code quality are subjective, and coders widely, strongly, and frequently disagree. However, having someone else look at your code is
extremely valuable, especially if that other person is at a significantly different level of competency (i.e. WC+SC, or SC+WC): WCs find confusing parts of SC's code, SC's find wrong parts of WCs code. SC+SC yields fewer changes at review-time, as SCs are better at defending their practices. WC+WC misses obvious problems (maybe).