[ACCEPTED]-Why are many languages case sensitive?-case-sensitive

I don't think you'll get a better answer 6 than "because the author(s) of that language 5 thought it was better that way". Personally, I 4 think they're right. I'd hate to find these 3 lines anywhere in the same source file (and 2 refer to the same object+method)...

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

I don't 1 think anyone would be happy to see this...

Unix.

Unix was case sensitive, and so many 18 programming languages developed for use 17 on Unix were case sensitive.

Computers are 16 not forgiving - an uppercase character is 15 not the same thing as a lowercase character, they're 14 entirely different. And back when processing 13 cycles, RAM and so forth were expensive 12 it wasn't seen as worth the effort to force 11 compilers and computers to be "forgiving", people 10 were just trying to get the things to work.

Notice 9 how case insensitivity didn't really become 8 something useful until things like Visual Basic came 7 along - once companies started to get invested 6 in the concept that getting the masses to 5 program was a good thing for their bottom 4 line (i.e., Microsoft makes more money if 3 there're more programs on Windows) did the 2 languages start to be friendlier and more 1 forgiving.

One interesting thing to consider is that 21 English is also case-sensitive. (I suspect 20 this is true for most natural languages, but 19 it may well not be true for all.)

There's 18 a big difference (where I live, anyway, near 17 the town of Reading) between:

I like reading.

and

I 16 like Reading.

Similarly, while many people 15 do capitalise incorrectly, and you can usually 14 understand what is meant, that doesn't mean 13 such writing is considered correct. I'm a stickler 12 when it comes to this kind of thing, which 11 is not to say I get everything right myself, of 10 course. I don't know whether that's part 9 of the inheritance of programming language 8 case sensitivity, but I suspect it may be.

One 7 distinct advantage of case sensitivity for 6 programming languages is that the text becomes 5 culturally insensitive as well. It's bad enough having 4 to occasionally spell out to a compiler 3 which text encoding is used for a source 2 file - having to specify which culture it's in 1 would be even worse :(

It's actually extremely practical, both 12 for the developer and for the language syntax 11 specification: lower/upper case distinction 10 adds a great deal of expressiveness to identifier 9 naming.

From the point of view of the language 8 syntax, you can force certain identifiers 7 to start with a lower or upper case (for 6 instance Java class name). That makes parsing 5 easier, and hence helps keeping the syntax 4 clean.

From a developer point of view, this 3 allows for a vast number of convenient coding 2 conventions, making your code clearer and 1 easier to understand.

My guess would be that case sensitivity 3 enlarges the name space. A nice trick such 2 as

MyClass myClass;

would be impossible with case-insensitive 1 compiler.

Case folding is only simple in English (and 9 for all characters < 128). The German 8 sz or "sharp s" (ß) doesn't have an upper case variant in the 7 ISO 8859-1 charset. It only received one 6 in Unicode after about a decade of discussion (and now, all 5 fonts must be updated...). Kanji and Hiragana 4 (Japanese alphabets) don't even know lower 3 case.

To avoid this mess, even in this age 2 of Unicode, it is not wise to allow case 1 folding and unicode identifiers.

ExpertSexChange

I believe this is a competitor to Stack 6 Overflow where you have to pay to read answers. Hmm... with 5 case insensitivity, the meaning of the site's 4 name is ambiguous.

This is a good reason 3 for languages being case-sensitive. Less 2 ambiguity! Ambiguity to programmers is considered 1 yucky.

Back when parsing and compiling was real 8 expensive and would take all night it was 7 advantageous to the compiler if it didn't 6 have to worry about case.

Once identifiers 5 came in to existence that were only unique 4 via their case it became very difficult 3 to go back. Many developers liked it and 2 there doesn't seem to be a big desire to 1 undo it.

Case sensitivity adds to language readability 7 by the use of naming conventions. You can't 6 write

Person person = new Person("Bill");

if your language is case insensitive, because 5 the compiler wouldn't be able to distinguish 4 between the Class name and the variable 3 name.

Also, having Person, person, PersoN, PeRsOn, and 2 PERSON, all be equivalent tokens would give 1 me a headache. :)

What is the capital form of i? I (U+0049) or 1 İ (U+0130)?

Capitalization is locale dependent.

Because they're as dumb as a box of frogs, for precisely the reasons 21 given for the opposite viewpoint in this 20 thread (I'm not even gonna ask what that's 19 about. Wood for the trees and all that).

When 18 FOOBAR = FooBar = foobar, you get to choose 17 your convention, and other coders can do 16 the same whether they share your preference or not. No confusion.

They also can't 15 get away with the stroke of genius that 14 is having a constant, function and variable 13 all with the same name in the same file, albeit 12 with different caps. Again, no confusion.

You 11 call your variable WebSite, they call theirs 10 Website, and which system gets confused? Not 9 an easy catch either, when you're scanning.

As 8 for lookups, is it really that much more 7 processing to convert the name to lowercase 6 before looking it up? Doing your own premature 5 optimisation is one thing, expecting it 4 from the developer of your language of choice 3 is a whole other level of missing the point.

...and 2 yet, all these answers saying case-sensitivity 1 reduces confusion. Sigh

Many (non-programming) languages (e.g. European 10 using the Roman alphabet) are case-sensitive, so 9 it's natural for native speakers of those 8 languages to use upper- / lower-case distinctions.

The 7 very idea that programming languages wouldn't be 6 case-sensitive is a historical artifact 5 arising from the limitations of early-generation 4 hardware (including pre-computer teletype 3 machines that used a 5-bit character code).

People 2 who argue for case-blind languages must 1 be unable to distinguish

IAmNowHere

from

IAmNowhere

(It's a joke! ;-)

How do you yell if you don't HAVE CAPS?! AHHH!

You 4 have to be expressive. But in all honesty, of 3 all the people in the world, those who work 2 with programming logic would be the first 1 to insist that differences are in fact differences.

There's also Common Lisp, which is a case-sensitive 12 language that many people mistakenly believe 11 is case-insensitive. When you type (car x) into 10 the Listener, it turns into (CAR X) for processing. It 9 is possible to define symbols with lower-case 8 names, but they have to be quoted with something 7 like |lower-case-symbol|. Therefore, typing in (car x) or (CAR X) or (Car X) all 6 works the same.

(Franz Lisp was at one point 5 introducing what they called "modern" capitalization, in 4 which the Listener would not fold cases, and 3 CL keywords would be in lowercase. I never 2 followed it well enough to know what happened 1 there.)

The upper-case of a letter isn't a universal concept. Java uses 7 Unicode, so if you wanted case-insensitive 6 Java, the meaning of your program could 5 change depending on what locale it was compiled 4 in.

Most languages don't let you put dots 3 or commas (or apostrophes or spaces) in 2 the middle of integer literals, probably 1 because that's also locale-dependent.

From .NET Framework Developer's Guide Capitalization Conventions, Case-Sensitivity:

The 7 capitalization guidelines exist solely 6 to make identifiers easier to read and 5 recognize. Casing cannot be used as a 4 means of avoiding name collisions between 3 library elements.

Do not assume that all 2 programming languages are case-sensitive. They 1 are not. Names cannot differ by case alone.

I have read this entire thread. I must believe 63 that those that report to have found value 62 in case sensitivity have never programmed 61 in a true high level language (which by 60 definition is case insensitive). K&R 59 admit that C is mid-level. After programming 58 in Pascal, Delphi, Lazarus, ADA, etc, one 57 learns that highly readable code is simple 56 to write and to get to run quickly without 55 obsessing on terse case sensitive constructs. After 54 all, readability is the first and last word 53 on the subject. Code is written for the 52 human, not the computer. No problems to 51 debug with case insensitive code. When 50 one moves down to a mid-level language, one 49 finds that there are NO advantages to case 48 sensitivity. There are however, a considerable 47 number of hours spent debugging case sensitivity 46 caused problems. Especially when patching 45 together modules from different coders. It 44 also appears that a large number of respondents 43 do not understand what is meant by case 42 insensitivity. Only the characters a-z 41 are affected. These are a sequential subset 40 of ASCII characters. Three or four bytes 39 of machine code make the compiler indifferent 38 to case in this range of characters. It 37 does not alter under-bar, numerals, or anything 36 else. The points about other languages and 35 character sets simply do not apply to this 34 discussion. The compiler or interrupter 33 would be coded to temporarily convert or 32 not convert the character for analysis at 31 compile time based on the being ASCII or 30 not.

I am shocked at the new languages 29 like Python that have come out repeating 28 the mistake that K&R made. Yes they 27 saved half dozen bytes in an environment 26 where the total RAM for compiler, source, and 25 object code was 1000 bytes. That was then. Now 24 Memory is not a problem. Now, for no sensible 23 reason, even the reserve words in Python 22 are case sensitive! I do not think I will 21 need to use "For" of "Print" as variable 20 or function name. But that possibility has 19 been preserved by the expensive of the time 18 spent contenting with the interrupter over 17 the exact case of each identifier. A bad 16 deal I think.

The closest thing I have read 15 to date in support of case sensitivity is 14 the comments on Hashing. But these rare 13 coding events that can be handled with careful 12 attention to detail do not seem to be to 11 be worth the pointless scrutiny a coder 10 must use to write case sensitive code. Two 9 views of the problem. One encourages bad 8 coding, set traps in the code, and requires 7 extra attention to be diverted away from 6 bigger concepts. The other has no down side, has 5 worked flawlessly in high level languages, and 4 allows flexibility were it does no harm. It 3 looks to me like yet another case of VHS 2 wins over BETA. It's just my two cents 1 worth here.

Lots of people here have said that it would 7 be bad for several forms of capitalization 6 to refer to the same thing, e.g.:

person
perSoN
PERSON

What would 5 be really bad is if these all referred to 4 different objects in code. If you've got 3 variables person, perSoN and PERSON all 2 referring to different things, you've got 1 a problem.

Case sensitivity doesn't really help case 9 consistency.

Foo.Bar  
foo.Bar  
fOO.bAR  

In a case insensitive language 8 that can be fixed automatically by the editor 7 easily. In a case sensitive language fixing 6 it it's harder as it may be legal. The editor 5 first has to ckeck if foo.Bar and fOO.bAR 4 exist and also has to guess that you typed 3 with the wrong case rather than forgetting 2 to declare the variable (as Foo is different 1 to fOO).

I think having a case-sensitive language 5 ENCOURAGES people to write poor code.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

Duh. You 4 couldn't think of a better variable name 3 than "ShoeSize" for the different purposes? There 2 is a billion different words you could use, but 1 you choose to just keep using ShoeSize instead?

Every example I've seen supporting case 12 sensitivity is based on a desire to write 11 bad, undescriptive code. e.g. the "date" vs. "myDate" argument 10 - these are both equally undescriptive and bad practice. Good 9 practice is to name it what it actually 8 is: birthDate, hireDate, invoiceDate, whatever. And 7 who in their right mind would want to write 6 code like:

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

Amazingly this is perfectly valid 5 case insensitive VB.Net code. The thought 4 that case sensitivity allows you to even 3 more flagrantly disobey good programming 2 practice is an argument against it, not 1 for it.

Because many people find employeeSocailSecurityNumber 2 just as readable as employee_social_security_number 1 and it is shorter.

And you could also (foolishly) just use 3 single-letters ("a" and "b" and "c") for 2 all classes, variables, functions, and methods.

But 1 WHY would you want to?

Use names that make sense, not:

function a(a)
{
    int a = a.a;
    return a
}

By typical coding standards, Person would 35 be a class, person a variable name, and 34 PERSON a constant. It's often useful to 33 use the same word with different capitalization 32 to mean something related but slightly different.

So, if 31 you had three staff members in your business 30 all called Robert, you'd refer to them as 29 Robert, robert and ROBERT would you? And 28 rely on people to know exactly which one 27 you meant?

Give them email addresses such 26 as Robert@widgets.com, robert@widgets.com, and 25 ROBERT@widgets.com if your email system 24 was case sensitive?

The potential for an 23 unauthorised breach of personal data would 22 be huge. Not to mention if you sent the 21 database root password to the disgruntled 20 employee about to be sacked.

Better to call 19 them Bob, Robbie, and Robert. Better still 18 to call them Robert A, Robert B and Robert 17 C if their surnames were e.g. Arthur, Banks, and 16 Clarke

Really - why on earth have a naming 15 convention that invites mistakes or confusion, that 14 relies on people being very alert? Are you 13 so short of words in your volcabulary?

And 12 as for the person who mentions the supposedly 11 handy trick "MyClass myClass" - why, why 10 why? You deliberately make it difficult 9 to see at a glance whether a method used 8 is a class method or an instance method.

Plus 7 you lost the chance to tell the next person 6 reading your code more about the particular 5 instance of the class.

For instance.

Customer 4 PreviousCustomer

Customer NewCustomer

Customer 3 CorporateCustomer

Your instance name needs 2 to ideally tell your colleague more than 1 just the class it's based on!

Learning is always easier by example so 45 here it goes:

C#(case sensitive but usable 44 from VB.NET which is case insensitive):

CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName      // Readable in both case sensitive and insensitive languages
_classMember   // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName   // Same style in case sensitive and insensitive languages
localVariable  // Never using prefix

Java 43 and JS use a style similar to C# but methods/functions/events 42 are declared like variables doSomething, onEvent.

ObjectPascal(Delphi 41 and Lazarus/FPC are case insensitive, like 40 ADA and VB.NET)

CConstantName     // One can use Def or no prefix, not a standard
IInterfaceName
TClassName        // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer      // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable    // Older code uses prefix for parameters not local vars

Using only OneCase and prefixes 39 for each type makes sense in all languages. Even 38 languages that started without prefixes 37 have newer constructs like Interfaces that 36 don't rely on case but use a prefix instead.

So 35 it's really not important if a language 34 is case sensitive or not. Newer concepts 33 were added to case sensitive languages that 32 were too confusing to be expressed by case 31 alone and required using a prefix.

Since 30 case sensitive languages started using prefixes, it's 29 only reasonable to stop using case with 28 the same identifier name someIdentifier 27 SomeIdentifier SOME_IDENTIFIER, ISomeIdentifier 26 and just use prefixes where it makes sense.

Consider 25 this problem: You have a class member called 24 something, a method/function parameter called 23 something and a local variable called something, what 22 case convention could be used to easily 21 differentiate between these ? Isn't it easier 20 to just use the most ConsistentCaseStyle 19 everywhere and add a prefix ?

Fans of case 18 insensitive languages care about code quality, they 17 just want one style. Sometimes they accept 16 the fact that one library is poorly written 15 and use a strict style while the library 14 might have no style or poor code.

Both case 13 sensitive and insensitive languages require 12 strict discipline, it makes more sense to 11 have only one style everywhere. It would 10 be better if we had a language that used 9 only StrictCase, one style everywhere and 8 prefixes.

There is a lot of poor C code, case 7 sensitivity doesn't make it readable and 6 you can't do anything about it. In a case 5 insensitive language you could enforce a 4 good style in your code without rewriting 3 the library. In a StrictCase language that 2 doesn't exists yet, all code would have 1 decent quality :)

MyClass myClass; would be impossible with 4 case-insensitive compiler.

Or you could be 3 smart and actually use 2 different words... that 2 better show what you are actually trying 1 to do, like:

MyClass myCarDesign;

Duh.

There is another reason languages are case 10 sensitive. IDs may be stored in a hash 9 table and hash tables are dependent on hashing 8 functions that will give different hashes 7 for differing case. And it may not be convenient 6 to convert all the IDs to all upper or all 5 lower before running them through the hash 4 function. I came across this issue when 3 I was writing my own compiler. It was much 2 simpler (lazier) to declare my language 1 as case sensitive.

If word separation is not important then 17 why do we put spaces between words? Therefore 16 I think that underlines between words in 15 a name do increase readability. Also lower 14 case with Capitalization of appropriate 13 characters is easiest to read. Lastly, it 12 is surely much easier if all words can be 11 conveyed by word of mouth - "Corporate Underscore 10 Customer" rather than "Capital C Lower Case 9 o r p o r a t e Underscore Capital C Lower 8 Case u s t o m e r"! - the former can be 7 spoken 'in one's head' the latter cannot 6 - I wonder how people who are happy with 5 case sensitivity handle these case sensitive 4 names in their brains - I really struggle. So 3 I feel that case sensitivity is not at all 2 helpfull - a retrogade step from COBOL in 1 my opinion.

Because people seriously overthink things.

Case 21 insensitivity works best when it's also 20 case-preserving and combined with a separation 19 between type and variable namespaces. This 18 means that:

• If you declare a class as 'TextureImage' and 17 then try to use it as 'textureImage', the IDE can autocorrect 16 you. This gives you the advantage that you'll 15 never have to hit the shift key unless you're 14 declaring an identifier or using an underscore.

• Just 13 like in Java and several other languages; it's 12 perfectly valid to type "MyClass myClass". The IDE and 11 the compiler should have no problem differentiating 10 between the use of a type and the use of 9 a variable.

In addition, case insensitivity 8 guarantees that 'o' and 'O' will never refer 7 to different objects. Common arguments include:

• "sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => and that someone will _never_ be allowed to join a programming team, so this is a strawman argument. even if they did manage to do so, case insensitivity is more the solution than the problem, because it means that you don't have to remember whatever crazy uppercase/lowercase combination they use.

• "you 6 can't internationalize case insensitivity 5 easily!"; => over 95% of programming languages are written in english for a very good reason. there are no competing character encodings and the vast majority of keyboards on earth are english based (in partial or whole). supporting unicode identifiers is perhaps the dumbest idea anyone has came up with in the 21st century; because a good portion of unicode characters are frikkin invisible surragates, reading code is hard enough without having to use google translate, and writing code is hard enough without having to copy-paste identifiers or use a character map.

• "but case sensitive languages 4 have more identifiers!"; => no, they have grammatically overloaded identifiers, which is substantially worse.

I don't use 3 any case-insensitive languages, but the 2 advantages are blatantly obvious if you 1 think about this sort of thing seriously.

A reasonable answer might be that the designers 3 of the language thought it would make the 2 language easier to understand thinking about 1 the future :)

I am very much in favor of case sensitivity. I feel like none of the above answers stressed 22 the "code style" aspect sufficiently.

I 21 worked with various programming languages 20 (case sensitive and insensitive) over the 19 years. And from my personal experience, I 18 can say that a lot of developers explicitly 17 exploited case insensitivity (out of laziness 16 and natural inconsistency) when it was possible 15 and when they didn't have experience with 14 case sensitive languages before.

This mostly lead to code that was harder to read and that also just looked utterly terrible.
I understand 13 the arguments for case insensitivity but 12 my hair stood on end so many times when 11 I saw code that was written by people who 10 worked solely with case insensitive languages.

Surely, this 9 issue could be theoretically "easily" addressed 8 by things like formatters etc.. but only 7 because something like that is possible 6 doesn't mean that people actually do it 5 in the real world.
It happened frequently 4 enough that the result of case insensitivity 3 gave me nausea.

Altogether, my personal experience 2 is that case sensitivity passively encourages 1 code style policies.