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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel