4 ms·
My two cents: write long procedures, write short functions. It is not very useful to break up long sequences of imperative commands (procedures) because chance
by ookdatnog 7y ago
My two cents: write long procedures, write short functions.
It is not very useful to break up long sequences of imperative commands (procedures) because chances are the procedure chunks you end up with are completely ad-hoc and non-reusable anyway. Also, as John Carmack puts it, "you should be made constantly aware of the full horror of what you are doing".
For pure functions, it's often a bit of a smell if they're very long; usually you can decompose them into smaller functions which are actually reusable, and you end up with small units that can be tested in isolation and are very easy to understand.
Generally speaking (not a hard rule), it's a win to have more of your program written as pure functions. But it cannot always be done in a sane way, in that case, write procedures and write them long.
- hinkley 7y agoBertrand Meyer, one of the original OOAD people, suggested a step farther: split decisions from actions. I really came to appreciate this while ramping up on test writing. Decisions are often trivial to decompose, reuse, and test. Actions not so much, and are sometimes defined by procedures in the literal sense. Still, if you have facility with the English language or aren’t ashamed to use a thesaurus, meaningful method names and boundaries can help break a problem down and let someone zero in on a bug.
- war1025 7y agoI like your distinction here. That fits well with how I find myself structuring code.