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.

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.

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright 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.
>
> 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.

Interesting, that's going in my tips.txt file. Quick question, if you don't mind. What would be the top three things you've learned that significantly made you a better programmer?

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.

On 10/25/2016 5:19 PM, bluecat wrote:
> Interesting, that's going in my tips.txt file. Quick question, if you don't
> mind. What would be the top three things you've learned that significantly made
> you a better programmer?

Ha, great question. Never thought about it before. Off the top of my head:

1. Never try to do two things at once, i.e. never mix:

   refactoring
   translation
   more than one bug fix at at time
   optimization
   feature addition

I sure endlessly beat people on github with clue-by-fours over this.


2. If the code looks ugly, it is guaranteed to not work properly. If you're stuck debugging someone else's code, look at the ugly bits first. (I've had several experienced developers tell me this, too.)


3. Anybody can write clever, complex code. It takes genius to write simple code.


4. Macros are like crack. The first hit feels great, but macros inevitably turn everything they touch into crap. It took me a loooong time to learn this. Some years ago I made a concerted effort to purge macros from the dmd front end, and have been purging them from the back end. I've been very pleased with the results.


5. Global variables are the Spawn of Satan. (They make code very hard to reason about.)


6. Nearly all bugs can be fixed with under 10 lines of code, and quite a few with 1 line. It's always a red flag for me when a fix PR has 200+ lines of code (test case lines of code don't count, neither do comments).


7. If you're stuck on a programming problem, go out for a jog. I often find the answer that way. What can I say, it works for me.

On 10/26/2016 12:53 AM, Walter Bright 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

I find it both funny and saddening how many reddit commentators complained about Linus version of that code is over-complicated.

"Prefer clear code over smart code" principle is good in general but sometimes it is over-applied to the point where incompetence gets glorified. And this sucks.

On 10/25/2016 3:53 PM, Walter Bright wrote:
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

The Hacker News thread:

https://news.ycombinator.com/item?id=12793624

On 10/26/2016 2:54 AM, Dicebot wrote:
> I find it both funny and saddening how many reddit commentators
> complained about Linus version of that code is over-complicated.
>
> "Prefer clear code over smart code" principle is good in general but
> sometimes it is over-applied to the point where incompetence gets
> glorified. And this sucks.


Any coding principle rigidly applied leads to disaster.

Reminds me of:

1. newbie - follows the rules because he's told to
2. master - follows the rules because he understands them
3. guru - breaks the rules because he understands that they don't apply

Am Tue, 25 Oct 2016 15:53:54 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> 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.
> 
> Eliminating loops is something D adds, and goes even further to making code a straight line.

On a more controversial note, I sometimes replace nested blocks of conditionals and loops with flat spaghetti code and goto with verbose labels. There are situations where you can explain straight forward what needs to be done first, second and last, but special cases and loops make it hard to tell from "normal" code.

  if (valueTooBig)
    goto BreakBigValueDown;

ProcessValue:
  ...
  return;

  // ====================== //

BreakBigValueDown: // makes big values manageable
  ...
  goto ProcessValue;


There is a concise piece of code that handles 90% percent of the cases and another block for anything that requires special handling. It can in theory also avoid costly memory loads for rarely used code.

> 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.

Interesting.

-- 
Marco

On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright wrote:
> On 10/25/2016 5:19 PM, bluecat wrote:
>

[snip]

I largely agree with your points 1.-7. (especially 1. and 7.). Also that gathering the data and acting upon it should be separate. However, principles might be at loggerheads. E.g. generics vs. specialization. Performance vs. fragmentation. Cf.

https://dpaste.dzfl.pl/dc8dc6e1eb53
vs.
https://dpaste.dzfl.pl/392710b765a9

(Andrei's improved search algorithm that got a performance boost through manual inlining).

On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright wrote:
> 7. If you're stuck on a programming problem, go out for a jog. I often find the answer that way. What can I say, it works for me.

It's a common way to solve problem. Just concentrate yourself on something more pratical than problem-solving. It really works fine for me. When we have a hard problem to solve my boss always tell me to take a walk out of office or simple to go home to lunch. Then I come back with solution. It works.