On Wednesday, 26 October 2016 at 09:41:42 UTC, Walter Bright wrote:
> 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).

I find the most elegant bug fixes tend to be the ones with an overall reduction of code.

Though, sometimes things are rotten to the core and that net change of -10 lines comes from a +330, -340 diff....

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.

Personally, a large amount of control flow statements (and especially nested control flow) makes it difficult for me to understand what the code does (not to mention debugging it). Unfortunately, it can be difficult to eliminate (or hide) control flow without creating needless complexity in other parts of the program. For instance, Linus' "good taste" example uses pointers explicitly and I would argue that this too is "distasteful".

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

An obvious example of code that gathers information separated from code that performs an action is exceptions. :)

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
>

What would you say is the best way to write his "Initialize grid edges" code in D? Ideally, I would like something like this:

void initEdges(int val, ref int[GRID_SIZE][GRID_SIZE] grid) {
	map!(a => val)(chain(grid.row(0), grid.row($-1), grid.column(0), grid.column($-1));
}

but multidimensional arrays don't have built-in primitives like that (as far as I know).

On 10/26/2016 06:42 AM, Walter Bright wrote:
>
> 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

I always liked that principle. Tao Te Ching, if I'm not mistaken (though I might be).

On 10/26/2016 6:20 AM, Adam D. Ruppe wrote:
> I find the most elegant bug fixes tend to be the ones with an overall reduction
> of code.
>
> Though, sometimes things are rotten to the core and that net change of -10 lines
> comes from a +330, -340 diff....

Elegant fixes tend to mean a refactoring is included!

And it's not a hard and fast rule. It's just a red flag.

On Wednesday, 26 October 2016 at 10:48:34 UTC, Marco Leise wrote:
> 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.

Speaking of Linus, that's idiomatic in the Linux kernel for error handling.

I like using D's nested functions for simplifying code in the same kind of way.  Sometimes a tiny helper function can make a big difference.

On 10/26/2016 4:21 PM, sarn wrote:
> I like using D's nested functions for simplifying code in the same kind of way.
> Sometimes a tiny helper function can make a big difference.

I've also found that nested functions can nicely fix spaghetti code.

On Wednesday, 26 October 2016 at 09:54:31 UTC, Dicebot wrote:
> 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.

I'm unsure about Linus' version. For this example, I agree that it is elegant. It is fine in this specific case, because everything is local within a single function. In general, the trick to use a pointer to the element probably not a good idea.

The article/Linus does not explain the tradeoffs properly, which makes it dangerous advice.

On Thursday, 27 October 2016 at 08:24:54 UTC, qznc wrote:
> On Wednesday, 26 October 2016 at 09:54:31 UTC, Dicebot wrote:
>> 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.
>
> I'm unsure about Linus' version. For this example, I agree that it is elegant. It is fine in this specific case, because everything is local within a single function. In general, the trick to use a pointer to the element probably not a good idea.
>
> The article/Linus does not explain the tradeoffs properly, which makes it dangerous advice.

It's like everything in life, like playing an instrument for example - or indeed life itself. Nothing, not even the best advice, can replace experience - which comes with age. It's only when you have a lot of experience that you understand the advice given to you by your elders. Then you pass on the same advice - but the inexperienced have to make the same old mistakes all over again until they understand. Some never do, though.

On 10/27/2016 11:24 AM, qznc wrote:
> I'm unsure about Linus' version. For this example, I agree that it is elegant. It is fine in this specific case, because everything is local within a single function. In general, the trick to use a pointer to the element probably not a good idea.
> 
> The article/Linus does not explain the tradeoffs properly, which makes it dangerous advice.

I'd agree for some general language but considering it is Linus, C can be reasonably assumed. And in C land it doesn't even count as "trick", heavy nested pointer usage is widespread and even somewhat idiomatic - being comfortable with such code can be expected from any non-newbie C programmer.