... but this code is easier for newbies to understand! Your code is too complicated!
See Spot Run is easier for novice readers to understand than The Name of the Rose, but the latter is the better book.
Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem? (Though if your problem is teaching how to program, obviously your goal is different.)
Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem?
Because those are the people who'll be doing maintenance. Or so goes the reasoning.
Re:Who fixes the fixers?
chromatic on 2006-02-15T18:34:21
I know you know this, but if this is the reasoning on your project and if your project matters at all, you have bigger problems than inscrutable code.
I tend to agree. For maintainance reasons I can see helping people ignorant of the platform, or perhaps even the language in some rare cases, but definitely not the problem domain. It's not worth writing kernel code so that programming newbies can understand. You may be able to write much of it so that *kernel* newbies could pick it up and maintain it. Even then, some problems exist (e.g. code requiring complex multilevel locking semantics) that even if the code is clean and well designed, it will still require a programmer to come up to the understanding level of the code.
Complicated code is necessary at times, but the vast majority of the code should be so clear and easy to read that maintenance actions are obvious without requiring an in depth study.
Re:use Occam's razor
joel h on 2006-02-21T17:24:44
But, what's clear to an expert is NOT the same as what's clear to a novice. It's not a matter of "complicated" vs "clear", it's "concise" vs "wordy".
Concise, normalized, idiomatic code is very understandable to an expert, but opaque to a novice. Long, spelled-out, heavily commented code is most understandable to a novice, but frustrating to an expert who now has to read (and evaluate) maybe two to ten times as much code as is necessary. Some (short!) things that are obvious to experts may have no meaning at all to a novice.
Here's a sort of example of what I mean. Ovid's refactoring made this piece of code a little weirder, but no shorter, just for the goal of removing a little repetition. I think this particular refactoring was a bad idea but I can point to similar things I've done in the name of generalization.
http://use.perl.org/user/Ovid/journal/27851
See Spot Run is easier for novice readers to understand than The Name of the Rose, but the latter is the better book.
But without seeing the code in question how do we know whether the code is incomprehensible because it's a "better book". Maybe it was written by a gibbon given access to a keyboard and liberal quantities of scotch
Why optimize for people inexperienced with the language, platform, or problem domain when you could optimize for fixing the problem?
For me the danger is thinking that the two are always mutually exclusive.
I've written incomprehensible code that (after my stupidity was pointed out by my pair partner) was instantly made comprehensible by a couple of abstract-method refactorings and some better naming. Sure the first version was comprehensible to somebody who knew the problem domain inside and out - but the refactored version was just as "good" but gained in maintainability.
Though if your problem is teaching how to program, obviously your goal is different
Isn't part of your job as a developer always teaching the next person who reads your code how it works? Shouldn't the code you write reflect that?
