Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I notice, in C# i use very short variable names EVERYWHERE. My code is polluted with
foreach(var (v|f|i) in SOMETHING)
for(int (i|n|z)=0
var (ret|r) = blah();
...
return ret;
var sw = new StringWriter();
using(var r = cmd.ExecuteNonQuery()) {
while(r.Read()) {
r.GetSomething(3)
I dont know if this is bad or ok. I can certainly read it. I havent looked at code 5months ago or older so i cant say if i understand old code. All my functions are short and do one thing so by reading the function you can get a good idea what the variable is, especially since theres <=5vars in a function.
People use to yell at me about not using good variable names. Am i not using good variable names or is this ok?
Write code for humans to read. A good rule of thumb is the bigger the scope in which a variable is used, the more descriptive its name should be. Function parameters especially should have very descriptive names, with the exception of functions where it is obvious what the parameter does, as in
double sqrt(double n)
However, if it's something commonly given a short name and used in a small scope, then use a short name. Examples:
//these are okay
var sb = new StringBuilder();
var sw = new StringWriter();
var cmd = new SqlCommand();
for(var i = 0; i< count; i++) {}
Unless your code is minified, you shouldn't see vars like this all over the place. Your code should be effortlessly intelligible.
I recall hearing that we ought all code as if the next person to manage our project is a psychopathic killer who knows where you live.
Using short variable names for local variables is okay as long as the scope is limited.
Personally, I find that for simple usage short concise variable names tend to be easier to read than longer ones.
using (StreamReader sr = new StreamReader(inputStream))
{
sr.ReadByte();
}
As opposed to:
using (StreamReader streamReader = new StreamReader(inputStream))
{
streamReader.ReadByte();
}
It's really all about readability. Every situation is different, and developer teams are different. Follow the coding standard for the project, if that exists. If not, follow the style of existing codebase, if that exists.
I agree with some of the answers here say that variables names should have good names. But I believe that presupposes that an object has semantic value. Sometimes, it doesn't. In some cases, you just need an instance of a specific object to perform some small task, after which it becomes irrelevant. In cases like this, I believe that abbreviated identifiers are acceptable.
Note: Just because the usage of a variable is limited in its scope does not necessarily mean that an meaningless name is okay. If there is a good name that represents what the object does, then it should be used. If you can come up with a variable name that answers 'Why?', then that name is far preferable.
Also, using 'i' and 'j' for for indexes is well understood by developers. By convention, loop counter variables have been named this way since the days of FORTRAN.
for (int i = 0; i < 10; i++)
{
for (int j = 0; j < 10; j++)
{
PerformOperation(i,j);
}
}
Some years ago I discovered what happens if I made my functions short:
I could understand them. My brain is small, and long functions don't fit.
Classes get complicated (lots of functions). But Extract Class produced small, cohesive, single-purpose classes. Again, small brain, so small classes required.
The number of variables in a function (or class) is small. Remembering which is which from declaration time to use time is easy, because the distance is short.
The number of scopes in my functions is small, so I don't have to figure out which variables go where.
With all of that in place, how I name my variables doesn't matter much. The names don't have to make up for code that is otherwise hard to understand.
Since the number of variables in a scope is small, and the purpose obvious, I rarely need to put any effort in to choosing a descriptive name. Since I don't want to strain my small brain any more than I have to, I never abbreviate. My default name for a variable is the name of the type. E.g. class Foo goes in variable foo. In my code, if it's ever something different, you know something special is happening, and you should pay attention.
In the old days, my no-abbreviation habit would have produce unwieldy code, but since my methods and classes are small, the code doesn't suffer.
It's not just a matter of good variable names (which is a good idea) but rather if someone else could make sense of what you've written relying on the comments as well as the variable names.
Sure, for things like counters or simple actions short and concise names make sense. For more complex algorithms or something that is a little harder to read, you'll want to elaborate to the extent that the code is clear.
Every shop and every developer is different. At the end of the day, try to write your code with consideration for the next guy that might have to maintain it.
Using one letter variable names as indexes in loops or in short well defined blocks is normally considered ok. However, there is nothing wrong with using descriptive camel case names that convey meaning to others reading your code, for things like function arguments and local variables.
With limited exceptions, no - this is not OK. There's just no excuse any longer for single letter or overly abbreviated variable names. Even if you're a hunt-and-peck typist, intellisense means you almost never have to spell anything out. If you continue to name variables this way you are punishing both yourself any anyone unfortunate enough to be tasked with maintaining your code.
Would I consider it a bad coding style? Well, yes.
If you were working with me on same code I'd repeatedly remind you to name your variables better. In short, good code should be readable by other developers without much trouble and good variable names help a lot. Maybe you don't have problems reading your code even after a while, but the question is whether someone who has never worked on that good would be equally fine with it.
There are a few exceptions where I think that short variable names are okay:
Indexes (mostly in for loops) such as:
for (int i = 0; i < 10; i++)
{
}
Variables used in a very limited scope, such as Linq queries, lambda expressions or some of the examples already mentioned like Streamwriters and -readers and such are another example where I think that short variable names are fine.
Furthermore it's always a question of how readable your code eventually is. The reason why I would be constantly nagging at people who use short variable names is that for me that it is an indicator that they generally don't care about how readable their code is (especially for others).
I have no idea how you can keep track of things when you have variable names like that.
Generally, its much better to have longer names that actually describe the variables. The thing to strive for is for anyone to be able to read the code and understand whats going on, to be able to understand what they are for etc =)
It seems like the average length of my variable names increases by one every year I spend writing (and more importantly reading) code.
It should be immediately clear what any variable is for just by looking at a few lines of code. This can either be due to a nice variable name or the context.
About the only time I use short variable names is either if a short name is entirely descriptive (ie, x & y in a situation dealing with coordinates) or it's a utility function that operates on a data type (ie, capitalize the first letter of this string. It's a string, what else can you say about it? I named it S.)
I might not know what 'r' is later on in the code. Also, variable names are one thing, but you should be commenting code for the verbose explanation.
NB: This should probably be a community wiki as there's no definite answer.
This is bad. This is unmaintainable.
Short variables have their place. There is really no reason to write
for(int iterator; iterator
The rule of thumb is: One letter per screen of reach. With standarized 24 lines screen.
The exception is picking one-two extremely frequently used globals or semi-globals like pointer to the data storage or THE input data pointer, and make them 1-3 letters long. But anything else - use reason. Short loops - one letter. Locals of a function - 3-5 letters. Class variables - full word. Library class/function names - two words.
I don't see any reason to use short variable names that say nothing. We live in 21st century, we've got IDEs with IntelliSense (or other autocompletion)! Just press Ctrl+Space and it will advice you normal name for your variable depending on variable type, e.g.
StringBuilder <Ctrl+Space> stringBuilder;
List<Person> <Ctrl+Space> persons;
It is even easier than to type something like sb or another short name. No reason to use short names anymore.
P.S.: The only exception for me are counters like i, j, k in for loop.
I tend to prefer short "cryptic" variables (Symbols, in Mathematica) combined with descriptive comments.
Mathematica already has VeryLongFunctionNames for built in commands, and adding my own often spreads out code more than I care for.
I find it easier to read a shorter block of code where I can see everything at once, alongside a series of symbol descriptions.
Related
According to General Naming Conventions of .NET framework:
X DO NOT use abbreviations or contractions as part of identifier names.
For example, use GetWindow rather than GetWin.
X DO NOT use any acronyms that are not widely accepted, and even if they are, only when necessary.
I've once consider GetName can be used for my method, but I believe it's not so sematically meaningful.
In order not to deviate too far from the naming convention, I've tried to figure out widely accepted acronyms, but I just run out of ideas for the following method:
String GetExplicitInterfaceMemberImplementationName(MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}
For this case, it is, in fact, not really longer than the statement, but just the identical length; and Type.Delimiter should be used rather than ".". However, the naming problems so often bothers me.
So, what method name should I declare? And for the long-term solutions, what can I do?
For an additional question, is there an API out of the box does the same thing?
Edit 1:
Stop and think, such a good suggestion for me.
For the purpose of its statement, also for semantic and not breaking the naming conventions, I got an idea from [AddAttributeStoreCommand.TypeQualifiedName Property]; so I now declare it as:
public static String GetTypeQualifiedName(this MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}
Yet, a long-term solution hasn't come up ..
Edit 2:
I'm not sure whether it's a good practice to name like this ..
public static String GetTypeDotItsName(this MemberInfo info) {
return info.DeclaringType.Name+"."+info.Name;
}
Code Complete 2nd Edition has this to say about method name length:
Make names of routines as long as necessary
Research shows that the optimum average length for a variable name is 9 to 15 characters. Routines tend to be more complicated than variables, and good names for them tend to be longer. Michael Rees of the University of Southampton thinks that an average of 20 to 35 characters is a good nominal length (Rees 1982). An average length of 15 to 20 characters is probably more realistic, but clear names that happened to be longer would be fine.
Note the word average. If the method name is as clear as possible, and it's 50 characters, then whatever. It's fine.
However, the book does mention another thing a few paragraphs up:
If you have routines with side effects, you’ll have many long, silly names, The cure is not to use less-descriptive routine names; the cure is to program so that you cause things to happen directly rather than with side effects.
Of course, side effects aren't the issue here, but you can extend the idea. Ask yourself "Is this long, silly name popping up because I'm doing overly complicated stuff?" If you're sure that you need an ExplicitMemberInterfaceImplementationName, then fine, but it can at least be something to stop and think about.
1) Put in the information that is needed to make the purpose of the method clear. You can probably halve the length of your example name without any loss of understanding about what it fits.
2) guidelines are guidelines. Don't slavishly follow rules when they become counter productive. If using an abbreviation makes it easier to read and understand the code, use abbreviations. The main thing is to try to limit abbreviations to long names that are commonly used, and use intuitive and commonly used abbreviations for them, so that anyone reading your code can easily work out what they mean. For example, decl is a common abbreviation for declaration, and difficult to mistake for anything else.
3) sometimes you can avoid the need to abbreviate by using a synonym.
I think you could probably drop interface and member from your name without losing the meaning.
But perhaps the "explicit interface implementation name" is actually the "explicit name" - explicit has a well defined meaning, especially in the context if your class, and you can always add the fully watertight legal definition in your documentation comment. So: "GetExplicitName"
The example below may not be problematic as is, but it should be enough to illustrate a point. Imagine that there is a lot more work than trimming going on.
public string Thingy
{
set
{
// I guess we can throw a null reference exception here on null.
value = value.Trim(); // Well, imagine that there is so much processing to do
this.thingy = value; // That this.thingy = value.Trim() would not fit on one line
...
So, if the assignment has to take two lines, then I either have to abusereuse the parameter, or create a temporary variable. I am not a big fan of temporary variables. On the other hand, I am not a fan of convoluted code. I did not include an example where a function is involved, but I am sure you can imagine it. One concern I have is if a function accepted a string and the parameter was "abused", and then someone changed the signature to ref in both places - this ought to mess things up, but ... who would knowingly make such a change if it already worked without a ref? Seems like it is their responsibility in this case. If I mess with the value of value, am I doing something non-trivial under the hood? If you think that both approaches are acceptable, then which do you prefer and why?
Thanks.
Edit: Here is what I mean when I say I am not a fan of temp variables. I do not like code like this:
string userName = userBox.Text;
if (userName.Length < 5) {
MessageBox.Show("The user name " + userName + " that you entered is too short.");
....
Again, this may not be the best way to communicate a problem to the user, but it is just an illustration. The variable userName is unnecessary in my strong opinion in this case. I am not always against temporary variables, but when their use is very limited and they do not save that much typing, I strongly prefer not to use them.
First off, it's not a big deal.
But I would introduce a temp variable here. It costs nothing and is less prone to errors. Imagine someone has to maintain the code later. Better if value only has 1 meaning and purpose.
And don't call it temp, call it cleanedValue or something.
It is a good practice not to change the values of incoming parameters, even if you technically can. Don't touch the value.
I am not a big fan of temporary variables.
Well, programming is largely about creating temporary variables all over the place, reading and assigning values. You'd better start to love them. :)
One more remark regarding properties. Although you could technically put a lot of logic there, it is recommended to keep properties simple and try not to use any code that could throw exceptions. A need to call other functions may indicate that this property is better be made a method or that there is some initialization code needed somewhere. Just rethink what you're doing and whether it does really look like a property.
I just installed Reshaper 4.5 and it has come up with the following suggestions:
return this.GetRuleViolations().Count() == 0; -- REMOVE this.
new string[] { this.ID.ToString(), this.Registration } -- REMOVE string, MAKE ANONYMOUS TYPE
int i = Method.GetNumber(); -- REPLACE int WITH var
Should I do these?
I think in some cases it is going to make the code less readable but will it improve performance? what are the benefits of making these changes?
Thanks
1) The explicit this pointer is only necessary when the reference would otherwise be ambiguous. Since GetRuleViolations is defined on the type, you most likely do not need this.
Another point here is that if GetRuleViolations return an IEnumerable of something, you will generally be much better off using Any() instead of Count() == 0 as you risk enumerating the entire sequence.
2) String can be inferred from the initialization.
3) Resharper prefers var over specific types.
Apart from the obvious benefit of your little square going green, if you are writing code that will be maintained by someone else later, it makes good sense not to use your personal preference in coding syntax. Resharper is becoming useful in formatting code in a way that is recognisable to a very wide audience.
I belong to the school of thought that says it doesn't matter who's way is right. If we all stick to a pattern, we'll all find it easier to read each others code.
So, in my humble opinion, don't change the default resharper settings. Just accept that if you use the defaults, you make life simple for everyone.
I think the first one is for the purpose, if you want to make "GetRuleViolations()" a static method. Then you have not to remove the "this" identifier.
For the 3rd one - the one that annoys me the most. It provides the reader with less information and i think it's just a matter of showing off a newish feature.
I'd say - use var when you know the return type and use the correct object type when you do not like this:
var reader = new XmlReader(.... // Implicit
XmlReader reader = SomeClass.GetReader() // Explicit when you can't be sure
First one: Resharper is asking about removing this which is just a style thing to me. Nothing more, keeping it won't harm performance in any way. It is just a matter of readability.
For second and third: Resharper normally prefers using var instead of specific data type, that's why the suggestions. I believe it is a matter of personal choice and provides no extra gain other than readability.
The first seems unclear to me. You usually don't have to prefix this. as long as there are no ambiguities, which I cannot tell from this example. Resharper is probably right. The other two won't improve performance, the compiled result will be the same. It's just a matter of taste and, of course, your coding guidelines.
The first one should be configurable. As far as I remember, you can tell ReSharper whether you want to have "this." in front of only fields, methods, both or none.
Using "var" will not change anything in the generated CIL code, so the performance will stay the same. I haven't used ReSharper for some time and I don't know why it promotes anonymous types so aggressively, but one advantage of "var" is that it's more resistant to change.
Meaning if, instead of calling Method.GetNumber(), you called a wrapper, eg. Filter(Method.GetNumber()) in the same line that returns a Nullable, you won't have to update the variable's type.
None of these will have any effect on performance, only on readability.
I find suggestions 1 and 2 to be more readable, and 3 less readable than your original code.
But you don't need to just follow these suggestions if, e.g., you find them less readable or if they violate your company's code style standard. When you put the cursor on the squiggly line, press Alt-Enter to show the list of Contex Actions. One of them will be to to change the severity of the inspection; you can not show it at all or show it as a hint. You can find a complete list of inspections at ReSharper | Options | Code Inspection | Inspection Severity.
For quick tasks where I only use an instantiated object once, I am aware that I can do the following:
int FooBarResult = (new Foo()).Bar();
I say this is perfectly acceptable with non-disposable objects and more readable than the alternative:
Foo MyOnceUsedFoo = new Foo();
int FooBarResult = MyOnceUsedFoo.Bar();
Which do you use, and why?
Would you ever use this type of anonymous instantiation in a production app?
Preference: with parenthesis "(new Foo()).Bar();" or without "new Foo().Bar();"?
(Edited to abstract question away from Random class)
Side note regarding random numbers: In fact, no, your specific example (new Random().Next(0,100)) is completely unacceptable. The generated random numbers will be far from uniform.
Other than that, in general, there is not much difference between the two. The compiler will most probably generate the exact same code in either case. You should go with the most readable case (long statements might harm readability; more code will do it too, so you have to make the trade-off in your specific case).
By the way, if you chose to go with the single line case, omit the unnecessary parens (new MyObject().Method() will do).
You might want to consider the implications of using the code in the debugger. The second case will allow you to inspect the object you've created, whereas the first won't. Granted you can always back out to the second case when you're attempting to debug the code.
I've done it both ways and don't really have a preference. I prefer whatever looks more readable, which is highly dependent on the complexity of the class and method being called.
BTW -- you might want to pick a different example. I fear that your point might get lost in discussions over the best way to generate random numbers.
If you are only using the object once, the first way is better all the time.
It is shorter and clearer, because it makes it explicit that you will not use the object later.
It will probably compile to the same CIL anyway, so there's no advantage to the second form.
First statement. It's more readable, has less code and doesn't leave temps around.
The second one is debugging friendly, while the first one isn't. The second wins only because of this.
In fact the first way, creating a temporary, is more readable for two reasons:
1) it's more concise
There's less code to read, there's no unnecessary local variable introduced, and no potential name clash with another local, or shadowing of any variable with the same name in an enclosing scope
2) it communicates something that the second form doesn't, that the object is being used temporarily.
Reading it, I know that that instance is never going to be used again, so in my "mental compiler" that I use to understand the code I'm reading, I don't have to keep a reference to it any more than the code keeps a reference to it.
As Mehrdad notes, though, doing it with a Random class isn't a good idea.
As he also notes, the redundant parentheses make it less concise; unless you're in a dusty corner of a language, assume that competent programmers know the language's operator precedence. In this case, even if I don't know the operator precedence, the alternative parse (calling new on a function's return) is nonsensical, so the "obvious" reading is the correct reading.
int RandomIndex = (new Random()).Next(0,100);
int RandomIndex = new Random().Next(0,100);
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Just wondering why people like case sensitivity in a programming language? I'm not trying to start a flame war just curious thats all.
Personally I have never really liked it because I find my productivity goes down when ever I have tried a language that has case sensitivity, mind you I am slowly warming up/getting used to it now that I'm using C# and F# alot more then I used to.
So why do you like it?
Cheers
Consistency. Code is more difficult to read if "foo", "Foo", "fOO", and "fOo" are considered to be identical.
SOME PEOPLE WOULD WRITE EVERYTHING IN ALL CAPS, MAKING EVERYTHING LESS READABLE.
Case sensitivity makes it easy to use the "same name" in different ways, according to a capitalization convention, e.g.,
Foo foo = ... // "Foo" is a type, "foo" is a variable with that type
An advantage of VB.NET is that although it is not case-sensitive, the IDE automatically re-formats everything to the "official" case for an identifier you are using - so it's easy to be consistent, easy to read.
Disadvantage is that I hate VB-style syntax, and much prefer C-style operators, punctuation and syntax.
In C# I find I'm always hitting Ctrl-Space to save having to use the proper type.
Just because you can name things which only differ by case doesn't mean it's a good idea, because it can lead to misunderstandings if a lot of that leaks out to larger scopes, so I recommend steering clear of it at the application or subsystem-level, but allowing it only internally to a function or method or class.
Case sensitivity doesn't enforce coding styles or consistency. If you pascal case a constant, the compiler won't complain. It'll just force you to type it in using pascal case every time you use it. I personally find it irritating to have to try and distinguish between two items which only differ in case. It is easy to do in a short block of code, but very difficult to keep straight in a very large block of code. Also notice that the only way people can actually use case sensitivity without going nuts is if they all rigidly follow the same naming conventions. It is the naming convention which added the value, not the case sensitivity.
I maintain an internal compiler for my company, and am tempted to make it a hybrid - you can use whatever case you want for an identifier, and you have to refer to it with the same casing, but naming something else with the same name and different case will cause an error.
Dim abc = 1
Dim y = Abc - 1 ' error, case doesn't match "abc"
Dim ABC = False ' error, can't redeclare variable "abc"
It's currently case-insensitive, so I could probably fix the few existing errors and nobody would complain too much...
Many people who like case-sensitivity misunderstand what case-insensitivity means.
VB .NET is case-insensitive. That doesn't mean that you can declare a variable as abc, then later refer to it as ABC, Abc, and aBc. It means that if you type it as any of those others, the IDE will automatically change it to the correct form.
Case-insensitivity means you can type
dim a as string
and VS will automatically change it to the correctly-cased
Dim a As String
In practice, this means you almost never have to hit the Shift key, because you can type in all lowercase and let the IDE correct for you.
But C# is not so bad about this as it used to be. Intellisense in C# is much more aggressive than it was in VS 2002 and 2003, so that the keystroke count falls quite a bit.
There's a lot of answers here, but I'm surprised no one pointed out the obvious example that also makes fun of a stackoverflow competitor:
expertSexChange != expertsExchange
Case is very important when you use camel case variable names.
I believe it enforces consistency, which improves the readability of code, and lets your eye parse out the pieces better.
class Doohickey {
public void doSomethingWith(string things) {
print(things);
}
}
Using casing conventions makes that code appear very standarized to any programmer. You can pick out classes, types, methods easily. It would be much harder to do if anyone could capitalize it in any way:
Class DOOHICKEY {
Public Void dosomethingwith(string Things) {
Print(things);
}
}
Not to say that people would write ugly code, but much in the way capitalization and punctuation rules make writing easier to read, case sensitivity or casing standards make code easier to read.
I believe it is important that you understand the difference between what case sensitivity is and what readability is to properly answer this. While having different casing strategies is useful, you can have them within a language that isn't case sensitive.
For example foo can be used for a variable and FOO as a constant in both java and VB. There is the minor difference that VB will allow you to type fOo later on, but this is mostly a matter of readability and hopefully is fixed by some form of code completion.
What can be extremely useful is when you want to have instances of your objects. If you use a consistent naming convention it can become very easy to see where your objects come from.
For example:
FooBar fooBar = new FooBar();
When only one object of a type is needed, readability is significantly increased as it is immediately apparent what the object is. When multiple instances are needed, you will obviously have to choose new (hopefully meaningful names), but in small code sections it makes a lot of sense to use the Class name with a lowercase first character rather than a system like myFooBar, x, or some other arbitrary value that you'll forget what it does.
Of course all of this is a matter of context, however in this context I'd say 9 times out of 10 it pays off.
Case sensitivity is madness! What sort of insane coder would use variables named foo, foO, fOo, and fOO all in the same scope? You'll never convince me that there is a reason for case sensitivity!
It gives you more options.
Bell
bell
BEll
are all different.
Besides, it drives the newbies that were just hired nuts trying to find out why the totals aren't coming out right ;o)))
Because now you actually have to type everything in a consistent way. And then things suddenly begin to make sense.
If you have a decent editor - one that features IntelliSense or the same thing by another name - you shouldn't have any problems figuring out case-sensitive namees.
I usually spend some time with Delphi programming on vacation, and most of the other time I use only C++ and MASM. And one thing's odd: when I'm on Delphi, I don't like case sensitivity, but when I'm on C++ - I do. I like case sensitivity, becouse it makes similar words (functions, variables) look similar, and I like non-case sensitivity because it doesn't put excessive restrictions on syntaxis.
From
.NET Framework Developer's Guide
Capitalization Conventions, Case-Sensitivity:
The capitalization guidelines exist
solely to make identifiers easier to
read and recognize. Casing cannot be
used as a means of avoiding name
collisions between library elements.
Do not assume that all programming
languages are case-sensitive. They are
not. Names cannot differ by case
alone.
I think there is also an issue of psychology involved here. We are programmers, we distinguish minutely between things. a is not the same ASCII value as A, and I would feel odd when my compiler considers them the same. This is why, when I type
(list 'a 'b 'c)
in LISP (in the REPL), and it responds with
(A B C)
My mind immediately exclaims 'That's not what I said!'.
When things are not the same, they are different and must be considered so.
It's useful for distinguishing between types in code.
For example in Java:
If it begins with a capital letter, then its probably a class.
if its ALL_CAPS its probably a constant.
It gives more versatility.
Feels like a more professional way of coding. Shouldn't need the compiler to figure out what you meant.
I felt the same way as you a long time ago when i used VB3/4 a lot more. Now I work in mainly C#. But now I find the IDE's do a great job of finding the symbols, and giving good intellisense on the different cases. It also gives me more flexibility in my own code as I can have differnt meaning to items with different cases, which I do a lot now.
Also a good habit if your working in Linux where referencing file names is case sensitive. I had to port a Windows ColdFusion application to work in Linux and it was an utter nightmare. Also some databases have case sensitivity turned on, imagine the joy there.
It is good habit though regardless of platform and certainly leads to a more consistent development style.
IMHO it's entirely a question of habit. Whichever one you're used to will seem natural and right.
You can come up with plenty of justifications as to why it's good or bad, but none of them hold much water. Eg:
You get more possible identifiers, eg. foo vs Foo vs FOO.
But having identifiers that differ only in case is not a good idea
You can encode type-info into a name (eg. FooBar=typename, fooBar=function, foo_bar=variable, FOO_BAR=macro)
But you can do that anyway with Hungarian notation
Because it's how natural language works, too.
In progamming there's something to be said for case sensitivity, for instance having a public property Foo and a corresponding private/protected field foo. With IntelliSense it's not very hard not to make mistakes.
However in an OS, case sensitivity is just crazy. I really don't want to have a file Foo and foo and fOO in the same directory. This drives me cray everytime i'm doing *nix stuff.
For me case sensitivity is just a play on scopes like thisValue for an argument and ThisValue for a public property or function.
More than often you need to use the same variable name (as it represents the same thing) in different scopes and case sensitivity helps you doing this without resorting to prefixes.
Whew, at least we are no longer using Hungarian notation.
Case-insensitive languages don't easily generalize to non-ASCII character sets. Proper case conversion for a language other than English is not a straightforward task, and depends on system locale, among other things.
Case insensitivity is very difficult, unless you restrict the syntax to ascii (or only apply the case insensitivity to the ascii characters), and also you need to restrict the locale.
The rules for determining upper and lower case of characters is neither well defined, nor is it lossless.
Some characters can have more than one 'lowercase' form. Some people will disagree as to what the correct uppercase form should be.
(Some languages and environments allow for almost character to be used in names)
Consider In C# what is the difference between ToUpper() and ToUpperInvariant()?
After working many years with legacy VBScript ASP code, when we moved to .NET we chose C#, and one of the main reasons was case sensitivity. The old code was unreadable because people didn't follow any convention: code was an unreadable mess (well, poor VBScript IDEs helped on that).
In C# we can define naming conventions and everybody must follow them. If something is not correctly cased, you can rename it (with refactoring, but that's an IDE feature) and there won't be any problem because the class or variable will be named the same way all across the code.
Finally, I think it's much more readable if everything is correctly cased. Maybe it's faster to write without case sensitivity, but from a code reviewing and maintaining point, it's not the best thing because skipping through the code looking for something is easier. For example it's easier to find all the foo strings at a glance than looking for foo, Foo, FOO, FOo...