Related
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.
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.
I'm not too quite sure about what i should do about a grouped set of classes.
My situation: I have 11 classes that relate only to the class Character.cs, but all of those classes (including Character.cs and CharacterManager.cs) are within the namespace Models.Characters.
Which is the more "proper" or preferred way of naming the classes:
(examples):
CharacterDetails.cs
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
or:
Details.cs
Sprites
Appearance
ClientRights
ServerRights
(They're all noticed in Models.Characters (so eg. Models.Characters.CharacterDetails, Models.Characters.Appearance)
Thanks in advance.
Personally for me it"depends". Usually I would prefix everything with the word Character to keep things consistant, however if you have everything already under the Character namespace the Character prefix could seem redundant.
I could easily see going with the shorter convention of Models.Character.[X] if there never will be another class called Details, if there for instance could be UserDetails then Details and UserDetails could be confusing when looking back at the code weeks or months from now and I would personally prefer then the CharacterDetails option.
In the end it is your personal preference, what more accurately describes your domain, Details or CharacterDetails?
Personally I'd stick with the second method as that is what namespaces are for: grouping related sets of classes. The first method is just making the class names longer with negligible benefits.
Your namespace already is grouping its classes under the Characters umbrella, so I would not name your classes with the Character moniker.
There is probably no right or wrong answer here. I find myself prefering your first style, but I have used the second style as well. I think in this specific situation if I were a caller of your API I would find it easier to read code that used the first style.
It is really a personal preference.
I would favor
CharacterDetails
CharacterSprites
CharacterAppearance
CharacterClientRights
CharacterServerRights
Because it is more readable.
You are typically going to have a using statement of
Models.Characters.Appearance
Unless you are going to do the full notation.
I would favor anything that would increase readability. It might matter on the project and the team you are working with. If it is just you than do what you like best and would help you maintain the code in the future.
As long as you pick one and consistantly use that throughtout your code, then whichever one you choose is the right one.
My personal choice is your second option. If your namespace is character, I see no reason to use the prefix character in the class name.
Think about ambiguity that may be created by naming class. For example if I have a class called "Thread" denoting "CharacterThread" (hypothetical) and if some other class uses two namespaces
Models.Characters
System.Diagnostics
I will have to fully qualify the Thread name everytime I use it ... which can be a pain sometimes
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 9 years ago.
Improve this question
What reasoning exists behind making C# case sensitive?
I'm considering switching from VB.NET to take advantage of some language features (CCR and yield), and understanding the reasoning behind this difference may make the transition easier.
[UPDATE]
Well I took the plunge three days ago. Learning C# hasn't been particularly hard, I could barely remember my C++ days in the late 90's though.
Is the Case Sensitivity annoying me? not as much as i'd thought... plus I am finding that it actually is advantageous. I'm actually really happy with the CCR as a asynchronous coordination programming model. If only I had more time on the current project i'd port the code base into C# to take full advantage. Wouldn't be fair to my client though.
Assessing my current project now and I'm seeing blocking threads EVERYWHERE! AHhhh!!!
[UPDATE]
Well i've been programming in C# for nearly a year now. I'm really enjoying the language, and I really REALLY hate crossing over to VB (especially when it is unavoidable!)
And the case sensitivity thing? not even an issue
C# is case sensistive because it takes after the C style languages which are all case sensitive. This is from memory here's an MSDN link which is not working for me right now I can't verify.
I would also like to point out that this is a very valid use case:
public class Child
{
private Person parent;
public Person Parent
{
get { return parent;}
}
}
Yes you can get around this using prefixes on your member variables but some people don't like to do that.
They were probably thinking "we don't want people using SoMeVaRiAbLe in one place and sOmEvArIaBlE in another.
Consider the variable names in the following pseudocode:
class Foo extends Object { ... }
...
foo = new Foo();
Having case sensitivity allows conventions which use case to separate class names and instances; such conventions are not at all uncommon in the development world.
I think the fact that case can convey information is a very good reason. For example, by convention, class names, public methods and properties start with an uppercase letter by convention. And conversely, fields and local variables start with a lowercase letter.
After using the language for years, I've come to really enjoy this, code is much easier to read when you can read information simply from the casing of the words.
And that's why people do this sometimes, and it can make sense:
Foo foo = new Foo();
I do that all the time, it's very useful. If you think about it in a more useful situation like this:
Image image = Image.LoadFrom(path);
It just makes sense sometimes to call the instance the same thing as the class name, and the only way to tell them apart is the casing. In C++ the case-sensitivity becomes even more useful, but that's another story. I can elaborate if you're interested.
I think that having case sensitive identifiers can make code more readable, through the use of naming conventions, well, and even without naming conventions, the consistency enforced by case sensitivity ensures you that the same entity is always written the same way.
C# inherits the case sensitivity from C and Java, which it tries to mimic to make it easier for developers to move to C#
There might have been some good reasons for making C case sensitive when it was created three decades ago, but there don't seem to be any records on why. Jeff Atwood wrote a good article advocating for that case sensitivity might no longer make sense.
Probably copied from C, C++, Java, etc. or may be kept the same on purpose so that its similar to what other langauges have.
It was just a matter of taste on the C# langauge designer team. I am willing to bet it was for comonality with other C family languages. It does however lead to some bad programming practices such as a private field and its associalted property differing only in the case of the first letter.
EDIT:
Why might this be cosidered bad.
class SomeClass
{
private int someField;
public int SomeField
{
get { return SomeField; }
// now we have recursion where its not wanted and its
// difficult for the eye to pick out and results in a
// StackOverflowException.
}
}
Prefixing private fields with an _ or an m might make it easier to spot. Its not a huge biggie and personally I sill do exactly what I have just said is bad (so sue me!).
Parsing is also a tiny bit easier for case-sensitive languages. As long as there's no good reason to choose the non-case-sensitive way, why bother?
You are looking at this in a very limited way - from your point of view. Language designers must take into account a whole other set of considerations: cultural reasons, compatibility with other languages, common coding practices etc
All modern languages use case-sensitivity: which ones don't?
As someone who used BASIC for a number of years I got very tired of developers using different cases for the same variable. This sort of thing is very tiresome to look at and encourages sloppy programming. If you can't be bothered to get the case right - what else can't you be bothered to do?
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.
My best guess as to the why it is case sensitive would be because Unix is case sensitive. Dennis Ritchie, the father of C also co-wrote Unix, so it makes sense that the language he wrote would coincide with the environment available at that time. C# just inherited this from its ancestor. I think this was a good decision on Microsoft's part, being that windows paths are not case sensitive.
I assume you'd like to see code like:
SomeField=28;
someField++;
somefield++;
SOMEFIELD++;
compiled as if SomeField in any casing variation is the same variable.
Personally, I think it's a bad idea. It encourages laziness and/or carelessness. Why bother properly casing the thing when it doesn't matter anyway? Well, while we're at it, maybe the compiler should allow misspellings, like SoemField++?
Naming. Names are hard to come by and you don't want to have to create a new name when talking about something similar or have to use some notation to set them apart.
Such scenarios are properties for fields or arguments in the constructor that you are about to assign to fields.
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...