David Rientjes <rientjes@xxxxxxxxxxxxxxxxx> writes:
> Your argument of saying to yourself "if line_width cannot fit max + len
> then we do this" has no relevance at all. I can say "if max + len is too
> big for line_width we do this" just the same.
Actually that is exactly my point. "Just the same". There is
no reason to choose one way or the other from purely logical or
mathematical point of view.
Comparisons written always in textual order, when one gets used
to, takes less thinking to parse and understand, and that is
what I'm used to. Have number line handy in your head and you
will hopefully like it too ;-).
>> Well, the program _firstly_ matches the logic flow better, and
>> _in_ _addition_ if you write it another way it becomes
>> unnecessarily too deeply indented. So while I agree with you as a
>> general principle that indentation depth should not dictate how
>> we code it does not apply to this particular example.
>
> This is a ridiculous argument. The C code will emit the exact same
> assembly regardless of how you write it. You say that you wrote it that
> way to avoid idents which is an absolutely horrible way to dictate the
> code you use.
I guess probably I was unclear (I did not talk anything about
code generation -- where did it come from?). I say I wrote it
that way _firstly_ because the flow of the program matches
exactly what I saw the code needed to do -- if A I do not have
to do anything else if B I do this else I do that. In addition
not having that "do nothing" made the code indent unnecessarily
deep but that is "in addition" and not the primary cause. It
was an added bonus.
> And in one of your patches you had:
> if (...)
> ;
> else {
> ...
> }
>
> without any other if statements.
Yes, indeed that was very funny looking.
It was refactored from the final one that had "else if" in the
middle (else if was to add the non-linear scaling). I agree
that any sane would not have done that if that was the real
first version.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html