Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 27 Sep 2006, Junio C Hamano wrote:

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

Nothing about this is "mathematical" at all and I never claimed it was.  
But there _is_ a reason to choose one way over the other and that is 
because the MAJORITY of programmers do it one way and YOU do it another 
way.  Why is it so hard to write all the code in the same style so that 
there is as little variation in the code as possible?

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

Doing what you prefer and not what the majority of your developers do is 
the first step to a stagnant source tree.

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

The concept of code generation is the whole point.  Both of our styles 
emits the same assembly code so by definition there is no difference since 
it achieves the exact same goal.  But there's a reason git is written in C 
and not in assembly and that reason is not just for portability.  A 
.c source file is the bridge between most programmers and assembly and 
since our coding styles differ but emit the same assembly, then it 
inherently comes with a freedom in how it's written.  And on a 
collaborative project such as git, that freedom should be confined to 
resembling the surrounding source code.

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]