Linus' idea of "good taste" code

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Tue Oct 25 18:19:37 PDT 2016


On Tue, Oct 25, 2016 at 03:53:54PM -0700, Walter Bright via Digitalmars-d wrote:
> It's a small bit, but the idea here is to eliminate if conditionals where possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
> 
> This is something we could all do better at. Making code a straight
> path makes it easier to reason about and test.

Not only easier to reason about, but probably performs better too.
Conditionals introduce pipeline hazards. (Though, arguably, not very
significant here because the loop would dominate the running time.)


> Eliminating loops is something D adds, and goes even further to making
> code a straight line.
> 
> One thing I've been trying to do lately when working with DMD is to
> separate code that gathers information from code that performs an
> action. (The former can then be made pure.) My code traditionally has
> it all interleaved together.

Separation of concerns is a typical "good taste" practice. It's why the
range-based pipeline idiom is so effective. When you compound multiple
concerns into a single piece of code, it inevitably gets tangled into a
complex mess that has lots of room for bugs to hide in. It's that whole
philosophy with Jackson Structured Programming again: make your code
structure 1-to-1 with your data structure, and edge cases and ad hoc
complexities vanish, along with their respective bug potentials.

If the input structure doesn't match the code structure for whatever
reason, say for algorithmic reasons, the best approach is to transform
the data into a matching structure first, then operate on it. I.e., your
"gather data, then operate on it" idea.  Trying to do both at the same
time typically leads to well-known warning signs: boolean flags,
recycled variables with conflicting meanings, proliferating
if-statements, complex looping conditions, etc., all the result of ad
hoc attempts at resolving the structure conflict between data and code.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.


More information about the Digitalmars-d mailing list