Develop Reference

Should I have a method name longer than its statement?

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"

.net code readability and maintainability [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There Currently is a local debate as to which code is more readability
We have one programmer who comes from a c background and when that programmer codes it looks like
string foo = "bar";
if (foo[foo.Length - 1] == 'r')
{
}
We have another programmer that doesn't like this methodology and would rather use
if (foo.EndsWith("r"))
{
}
which way of doing these types of operations is better?

EndsWidth is more readable to someone who has never seen C or C++, C#, or any other programming language.

The second one is more declarative in style but I can't tell you objectively if it is more readable sine readability is very subjective. I personally find the second one more readable myself but that is just my opinion.
Here is an excerpt from my article:
Most C# developers are very familiar
with writing imperative code (even
though they may not know it by that
name). In this article, I will
introduce you to an alternative style
of programming called declarative
programming. Proper declarative code
is easier to read, understand, and
maintain.
As professionals, we should be
striving to write better code each
day. If you cannot look at code you
wrote three months ago with a critical
eye and notice things that could be
better, then you have not improved and
are not challenging yourself. I
challenge you to write code that is
easier to read and understand by using
declarative code.

Number 2 is better to read and to mantain.
Example: Verify the last 2 characters ...
Option 1)
if (foo[foo.Length - 1] == 'r' && foo[foo.Length - 2] == 'a')
{
}
Option 2)
if (foo.EndsWith("ar"))
{
}
last 3? last 4?...

I come from a C/C++ background and I vote for Endswith!

Readability rules, especially if it implies intent.
With the first example I must discover the intent - which is left for interpretation. If it appears to have a bug, how do I know that's not intentional?
The second example is telling me the intent. We want to find the end character. Armed with that knowledge I can proceed with evaluating the implementation.

I think the second way is better because it is more easy to read and because the first one duplicates logic of EndsWith method which is bad practice.

I think the right answer would be the one that is actually correct. EndsWith properly returns false for empty string input whereas the other test will throw an exception trying to index with -1.

Not only is EndWith more readable, but also more 'correct'.
As a rule, if there is a framework method provided to do the job ... use it.
What if foo == string.Empty?

IMO, the intent of the original author is clearer in the second example. In the first, the reader must evaluate what the author is trying to accomplish by pulling the last index. It is not difficult, but requires more effort on the part of the reader.

Both approaches are valid, but the endswith method is easier to read in my opinion. It also does away with the potential to make typing mistakes etc with the more complicated form..

EndsWith is probably safer. But the indexer is probably faster.
Endswith probably checks to see if the input string is empty. They will probably both throw null reference exceptions. And the indexer will fail is the length is 0.
As for readability, they both say the same thing to me, but I have been programming for a while. The .EndsWith(...) is probably faster to grasp without considering context.

It pretty much does the same thing. However, it gets more complicated with more than one character in the endswith argument. However, the first example is slightly faster as it uses no actual functions and thus requires no stack. You might want to define a macro which can be used to simply make everything uniform.

I think the main criteria should be which of these most clearly says what the developer wants to do. What does each sample actually say?
1)Access the character at position one less than the length, and check if it equals the character 'r'
2)Check if it ends with the string "r"
I think that makes it clear which is the more maintainable answer.

Unless and until it does not affect the program performance, no problem you can use either way. But adding code comments is very important for conveying what is being accomplished.

From an error handling standpoint, EndsWith.

I much prefer the second (EndsWith) version. It's clear enough for even my manager to understand!

The best practice is to write code that is easily readable. If you used the first one, developers that are debugging your code may say, "What is this dev trying to do?" You need to utilize methods that are easily explained. If a method is too complicated to figure out, retract several methods out of it.
I would definitely say the second one, legibility and simplicity are key!
Also, if the "if" statement has one line, DONT BOTHER USING BRACES, USE A SINGLE INDENTION

Remember that in classic C, the only difference between a "string" and an array of characters is that terminating null character '\0', so we had to more actively treat them accordingly and to make sure that we did not run off the end of the array. So the first block of code bases its thought process on the concept of an array of characters.
The second block of code bases the thought process on how you handle a string more abstractly and with less regard to its implementation under the covers.
So in a nutshell, if you are talking about processing characters as the main idea behind your project, go with the first piece. If you are talking about preparing a string for something greater and that does not necessarily need to focus on the mechanics of the ways that strings are built -- or you just want to keep it simple -- go with the second style.
Some of this might summarize others' contributions at this point, but more analogously put, are you playing "Bingo();" or are you "playing a game with a two-dimensional array of random integers, etc.?"
Hopefully this helps.
Jim

"Code is written to be read by humans and incidently run by computers" SICP
EndsWith FTW!!

Anthropomorphising interfaces - good or bad idea?

I have for some time tried to anthropomorphise (meaning human readable) the names I give to interfaces, to me this is the same as give an interface a role based name – trying to capture the purpose of the interface in the name.
I was having a discussion with other developers who think this is a little strange and childish.
What do the folks of SO think?
Examples (C# syntax):
public interface IShowMessages
{
void Show(string message);
void Show(string title, string message);
}
public class TraceMessenger : IShowMessages
{
}
public interface IHaveMessageParameters
{
IList<string> Parameters { get; }
}
public class SomeClass : IHaveMessageParameters
{
}

IThinkItsATerribleIdea

Of course you should always choose identifiers which are human readable. As in: transport the meaning which they convey even to somebody who is not as familiar with the problem to be solved by the code as you are.
However, using long identifiers does not make your identifiers more 'readable'. To any reasonably experienced programmer, 'tmp' conveys as much information as 'temporaryVariable' does. Same goes for 'i' vs. 'dummyCounter' etc..
In your particular example, the interface names are actually quite annoying since somebody who's used to developing object oriented systems will read the inheritance as 'is a'. And 'SomeClass is a IHaveMessageParameters' sounds silly.
Try using IMessagePrinter and IMessageParameterProvider instead.

Yes, that sounds like a good idea.
What's the alternative?
Code should be human-readable. Any fool can write code a computer can understand. The difficult part is writing code a human can understand.
Humans have to maintain the code, so it's pretty darn important that it is as easy to maintain as possible - that includes that the code should be as readable as possible.

Interfaces describe behavior, and so I name them so as to to communicate the behavior they are mandating. This 'generally' means that the name is a verb, (or adverb) or some form of action-describing phrase. Combined with the "I" for interface, this looks like what you are doing...
ICanMove, IControllable, ICanPrint, ISendMesssages, etc...
using adverbs as in IControllable, IDisposable, IEnumerable, etc. communicates the same thought as a verb form and is terser, so I use this form as well...
Finally, more important (or at least equally important) than what you name the interface, is to keep the interfaces you design as small and logically contained as possible. You should strive to have each interface represent as small and logically connected a set of methods/properties as possible. When an interface has so much in it that there is no obvious name that would describe all the behavior it mandates, it's a sign that there is too much in it, and that it needs to be refactored into two or more smaller interfaces. So, maming interfaces in the way you are proposing helps to enforce this type of organizational design, which is a good thing.

There's nothing strange about using simple human-readable names. But using the I for interface to also stand for the first-person I as though it's talking about itself... is a little unusual, yes.
But the bottom line is, whatever works for you and is understood by you and your team is fine. You gotta go with what works.

In my opinion this approach just adds a greater burden on the developers to come up with such names since it intergrates the I as part of a sentence. I don't find IDisposable for example to be more difficult to read than ICanBeDisposed.

In the OP's examples, the anthropomorphic way compares well against alternatives - eg: IShowMessages vs. something like IMessageShower. But - this is not always the case. Interfaces I have used when programming game objects include: IOpenClosable and ILockable. Alternatives like ICanBeOpenedAndClosed and ICanBeLocked would be more verbose. Or you could simply do IAmOpenClosable and IAmLockable - but then you'd be adding the "Am" just for the anthropomorphic effect with no real information benefit. I am all for minimizing verbosity if the same amount of information is conveyed.

So long as the semantics of what is trying to be achieved aren't lost and terseness isn't irreparably compromised (IDoLotsOfThingsWhichIncludesTheFollowingColonSpace...). I wouldn't generally mind somebody other than myself doing it. Still, there are plenty of contexts in which terseness is paramount, in which this would be unacceptable.

Intentionally using the 'I for Interface' convention in the first person seems a bit silly to be honest. What starts out as a cute pun becomes impossible to follow consistently, and ends up clouding meaning later on. That said, your standalone example reads clearly enough and I wouldn't have a problem with it.

Ab-using languages

Some time ago I had to address a certain C# design problem when I was implementing a JavaScript code-generation framework. One of the solutions I came with was using the “using” keyword in a totally different (hackish, if you please) way. I used it as a syntax sugar (well, originally it is one anyway) for building hierarchical code structure. Something that looked like this:
CodeBuilder cb = new CodeBuilder();
using(cb.Function("foo"))
{
// Generate some function code
cb.Add(someStatement);
cb.Add(someOtherStatement);
using(cb.While(someCondition))
{
cb.Add(someLoopStatement);
// Generate some more code
}
}
It is working because the Function and the While methods return IDisposable object, that, upon dispose, tells the builder to close the current scope. Such thing can be helpful for any tree-like structure that need to be hard-codded.
Do you think such “hacks” are justified? Because you can say that in C++, for example, many of the features such as templates and operator overloading get over-abused and this behavior is encouraged by many (look at boost for example). On the other side, you can say that many modern languages discourage such abuse and give you specific, much more restricted features.
My example is, of course, somewhat esoteric, but real. So what do you think about the specific hack and of the whole issue? Have you encountered similar dilemmas? How much abuse can you tolerate?

I think this is something that has blown over from languages like Ruby that have much more extensive mechanisms to let you create languages within your language (google for "dsl" or "domain specific languages" if you want to know more). C# is less flexible in this respect.
I think creating DSL's in this way is a good thing. It makes for more readable code. Using blocks can be a useful part of a DSL in C#. In this case I think there are better alternatives. The use of using is this case strays a bit too far from its original purpose. This can confuse the reader. I like Anton Gogolev's solution better for example.

Offtopic, but just take a look at how pretty this becomes with lambdas:
var codeBuilder = new CodeBuilder();
codeBuilder.DefineFunction("Foo", x =>
{
codeBuilder.While(condition, y =>
{
}
}

It would be better if the disposable object returned from cb.Function(name) was the object on which the statements should be added. That internally this function builder passed through the calls to private/internal functions on the CodeBuilder is fine, just that to public consumers the sequence is clear.
So long as the Dispose implementation would make the following code cause a runtime error.
CodeBuilder cb = new CodeBuilder();
var f = cb.Function("foo")
using(function)
{
// Generate some function code
f.Add(someStatement);
}
function.Add(something); // this should throw
Then the behaviour is intuitive and relatively reasonable and correct usage (below) encourages and prevents this happening
CodeBuilder cb = new CodeBuilder();
using(var function = cb.Function("foo"))
{
// Generate some function code
function.Add(someStatement);
}
I have to ask why you are using your own classes rather than the provided CodeDomProvider implementations though. (There are good reasons for this, notably that the current implementation lacks many of the c# 3.0 features) but since you don't mention it yourself...
Edit: I would second Anoton's suggest to use lamdas. The readability is much improved (and you have the option of allowing Expression Trees

If you go by the strictest definitions of IDisposable then this is an abuse. It's meant to be used as a method for releasing native resources in a deterministic fashion by a managed object.
The use of IDisposable has evolved to essentially be used by "any object which should have a deterministic lifetime". I'm not saying this is write or wrong but that's how many API's and users are choosing to use IDisposable. Given that definition it's not an abuse.

I wouldn't consider it terribly bad abuse, but I also wouldn't consider it good form because of the cognitive wall you're building for your maintenance developers. The using statement implies a certain class of lifetime management. This is fine in its usual uses and in slightly customized ones (like #heeen's reference to an RAII analogue), but those situations still keep the spirit of the using statement intact.
In your particular case, I might argue that a more functional approach like #Anton Gogolev's would be more in the spirit of the language as well as maintainable.
As to your primary question, I think each such hack must ultimately stand on its own merits as the "best" solution for a particular language in a particular situation. The definition of best is subjective, of course, but there are definitely times (especially when the external constraints of budgets and schedules are thrown into the mix) where a slightly more hackish approach is the only reasonable answer.

I often "abuse" using blocks. I think they provide a great way of defining scope. I have a whole series of objects that I use for capture and restoring state (e.g. of Combo boxes or the mouse pointer) during operations that may change the state. I also use them for creating and dropping database connections.
E.g.:
using(_cursorStack.ChangeCursor(System.Windows.Forms.Cursors.WaitCursor))
{
...
}

I wouldn't call it abuse. Looks more like a fancied up RAII technique to me. People have been using these for things like monitors.

Why do people like case sensitivity? [closed]

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...