Re: Linear programming is bad

[muesli]

I totally agree with this attitude and programming style. The biggest effect I like is that the purpose and algorithm of the code is clearly written, at the start, in the form of the procedure calls.

But in reality, I can't remember thinking about this as an issue: I just automatically program like this - it wouldn't occur to me to do it another way, and I'd probably refuse to. Same thing with going on a larger scale and talking about OO programming or refactoring. I would never just write new functionality into an existing class that made no sense there. I just do it correctly at the beginning - say, creating two extra classes to implement orthogonal functionality. Same with documenting my work. As far as I'm concerned, the thing isn't done until it's documented.

(This has gotten me into trouble with previous employers, who've said they have no time for comments or documentation. To me, though, it's part of the product.)

I think that Ovid starts out with the right propositions (don't add functionality you don't need - features that might be handy in the future), but then draws a conclusion I disagree with: That this style of coding is a feature that's optional functionality.

An auto engineering example:

* XP Done right: You don't want to build 4 cigarette lighters into a car because we think some people might want to run 4 accessories at the same time, and therefore we ought to support that hypothetical case.

But my whole point is that this isn't what we're talking about:

* Analogy with proper coding/documenting: You do put in seatbelts in cars, although strictly speaking, you don't need them to get from point A to point B. Because, as professionals, that's just how cars are made.

PS: In software, the end user is usually another programmer. If a programmer gave me long, or un-idiomatic code that's all one procedure and not documented, I'd give it back to them and say that their job isn't done yet. (And I have done this!)