Re: [PATCH] Drivemap module

[Javier Martín]

Hi there and thanks for playing The Game!

El lun, 04-08-2008 a las 20:50 -0400, Isaac Dupree escribió:
> Javier Martín wrote:
> > You understand my concern, but seemingly do not understand that in order
> > to conform to the Holy Coding Style you are asking me to write code that
> > can become buggy (and with a very hard to trace bug) with a simple
> > deltion! (point: did you notice that last word _without_ a spelling
> > checker? Now try to do so in a multithousand-line program).
> 
> well, maybe a bit off topic.
> But I can't imagine how, after code is written, I could 
> accidentally delete an "=" character even when editing it. 
> I prefer the (to me) intuitive meaning of (variable == 
> value) in my own code.  That particular problem has never 
> bitten me.  Although, in C++ coding style, a lot more local 
> variables are "const" and therefore the error could be 
> caught by the compiler anyway.  It seems like an odd 
> paranoia to choose.  Say, take "uint32_t".  It's only a 
> one-character deletion to become int32_t and then there is 
> subtle breakage.  "htons" and many other functions with 
> similar names and suffixes.  Etc.?  It's half C language and 
> culture, and half inevitable in programming, IMHO.
Sigh... Maybe I'm just a bit paranoid because I have been bitten by
similar problems (not in "if"s, but mainly in loop condition checks) and
they were painstakingly difficult to hunt down even in a good IDE like
Netbeans: I sometimes considered the possibility of my computer having
lost all sense of logic because I saw it singlestep into the "wrong"
branch until I noticed the = instead of ==. True, the possibilities of
causing such a change are very low.
> 
> point[2]: I half did notice the typo (only "half" because 
> I've trained myself not to be too distracted by people's 
> spelling), and I'm generally more precise when looking at 
> code (maybe). ;-)
So I thought, but even my own code dodges me at times, not to speak of
others' code...
> 
> Anyway, since "they" are more likely to maintain the code in 
> the long run than you, in general, the question is whether 
> the code is more likely to become buggy by their hacking on 
> it, if it follows project coding style or someone else's 
> (your) "safer" coding style.  Likely it's safer if using a 
> consistent programming style.  Although I personally don't 
> see that it's very helpful to have a style that makes things 
> down to the order of "==" arguments be consistent within the 
> project; haphazard only slows reading the tiniest bit, and I 
> don't think it makes a different what order the arguments are...

Hmm... I was partially expecting a flamefest to start. Pity ^^
Well, let's spill a little napalm: the GNU style bracing is extremely
silly!! Why the hell are the "if" and "else" blocks indented differently
in this example?
  if (condition)
    return 0;
  else
    {
      return -1;
    }
Nah, I'm not really bringing that issue, I was just joking, and in fact
I'm reconsidering my objections to the operator== arguments order rule,
even though I still consider my style safer and more sensible. If
someone else wants to express their opinion on that issue, do it fast
before I completely submit to Master Marco's will :D

Habbit

signature.asc
Description: Esta parte del mensaje está firmada digitalmente