Hello, On Wed, 30 Jul 2008, Paul Moore wrote: > On Tuesday 29 July 2008 10:47:59 pm Russell Coker wrote: > > > > But using idx, index, or even names such as "count" which refer to > > the meaning of the program might be more efficient overall. I've > > posted some more thoughts on this issue at the above URL. > > FWIW, you hit on my own selfish reasons for using "idx" instead of "i": > easier searching (my XEmacs config highlights search terms in red) and > greater "understandability". I wish to express my disagreement, but please do not take this as a request to alter the earlier patch rejection; I have no problem with it. When using local variables as loop indexes or something equally elementary, I always prefer "i" to "idx", "index" or "count". My rationale is the following: 1) The existing convention; I've seen C-code like: for (i = 0; i < MAX; i++) so many times that the "i" has almost become a part of the language syntax in my brain. I'd guess many C-programmers feel the same way. Granted, the "this is how it's always been" is a weak argument to support anything, but personally, I gain no more insight from the longer forms, so I prefer the more terse "i". 2) Related to the first; the existing code base. If I see 999, 99, or even 9 functions in the same program/module consistenly using "int i", I will under no circumstance use "idx" in my additional function, but insist that all the functions use the same variable naming scheme. If, for some reason, the dominant variable naming for a particular code base happens to be "idx", "index", or "count", then I will adapt to that style. Further, I always to try extend the adaptation principle to the positioning of braces, whitespace, etc. so that all the code looks as if written by one person (I mean style-wise). 3) As Russell says in his blog: "Of course for some uses (such as a loop counter) there is little benefit in using grep." Yes. I also fail to see the drawbacks of using "FILE *f" inside a single function. Granted, if the functions are 3000-line monsters (yeah, unfortunately those do exist), you might have to use a more descriptive naming, but for the saner lengths, I am not so sure. For monster functions, refactoring it to smaller chunnks is usually the correct solution anyway, not changing "FILE *f" to "FILE *configFile". 4) Related to the particular case I addressed in my original message, the Linux Kernel Documentation/CodingStyle says: "LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value." Best regards, vmk -- ************************************************************************ Tietotekniikkaosasto / Helsingin yliopisto IT Department / University of Helsinki ************************************************************************ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.