Using single characters for variable names in loops/exceptions

£可爱£侵袭症+ 提交于 2019-12-10 21:33:00

问题


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 - i for(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 of e.

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

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!