问题
I've had a couple of discussions with a co-worker about the use of single letter variable names in certain circumstances inside our codebase, at which we both disagree.
He favours more verbose naming convention for these, and I do not.
There are three scenarios in my opinion where I use single letter variable names:
- Loops -
ifor(int i = 0; i < 10; i++) { ... } - Lambda expressions in C# -
x/y/z:.Where(x => x == 5) - Exceptions -
e:try { ... } catch(ExceptionType e) { /* usage of 'e' */ }
These are the only scenarios where I would use it, and I obviously use more verbose naming conventions elsewhere.
My colleague put forward the following arguments for exceptions and loops:
i- it doesn't mean anything.e- it's the most common letter in the English language. If you wanted to search the solution for exceptions, you'd find lots of undesired instances ofe.
I accept these arguments, but have retorts that, if one does not know what i means in a for loop, then they probably shouldn't be a programmer. It's a very common term for loops and exceptions, as is e. I have also mentioned that, if one wanted, they could search for catch in the case of the exception.
I realise that this is subjective, but then, one could argue that coding standards are just that - opinions, albeit opinions by academics.
I would be happy either way, and will forward the results to him, but would rather that we (our company) continue to use a single coding standard, rather than have two developers with different opinions on what to use.
Thanks in advance.
回答1:
i doesn't mean anything
Yes it does. It's the index in a for loop or counter.
e is the most common letter in the English language. If you wanted to search the solution for exceptions, you'd find lots of undesired instances of e
This just doesn't even make any sense. Why would you search for e if you wanted to find instances of Exception?
Serioulsy, I'd just laugh at anyone who came out with these arguments. Everyone knows what i and e represent in these scenarios. They are universally accepted conventions. It sounds to me like your colleague is just trying to be a smart-ass.
Edit - This question reminded me of this wtf.
回答2:
If the lexical scope of a variable is more than 20 or 25 lines, then the variable should probably not have a single letter name. If a large number of variables in your code base have a lexical scope larger than 25 lines (or so), then your code base has a much bigger problem than can be dealt with by using a verbose naming convention.
回答3:
Another exception to the rule that I apply is naming of exception variables that need to be thrown. For instance, the code should read:
Exception yourToys = new Exception(...);
throw yourToys;
or
Exception up_in_a_bucket = new Exception(...);
throw up_in_a_bucket;
回答4:
I recently had a conversation with somebody about this.
I'm come to the opinion that, for operations that are a functional abstraction, using a "meaningful" name can be overstated.
For instance, in JavaScript:
myArrayOfNames.forEach ( function ( name ) { } );
myArrayOfNames.map ( function ( name ) { } );
myArrayOfNames.filter ( function ( name ) { } );
I generally use "each", "obj" or just "d" for these sorts of things, because I see these as course-grained abstractions. "name" really tells me nothing other than it's a name from an array of names.
Who cares? Because I've seen developers iterate reviews arguing about what is "meaningful". More than once.
So over the years, I gravitated towards settling it by saying, the operation is a functional abstraction (iteration) applied to a specific list of some kind. Reflect that language, and usage, in your code:
myUsefullyNamedArray.filter ( function ( d ) {
return ( 'someval' in d );
} );
来源:https://stackoverflow.com/questions/5802403/using-single-characters-for-variable-names-in-loops-exceptions