Slashdot Mirror
Who Needs Case-Sensitivity in Java?
David Barber asks: "I've just started learning Java, and to my exceptional disappointment it is as case-sensitive as C. I'd like to ask Slashdot readers to make the case for case-sensitivity in a programming language, because I can't see it. Although I've used C on and off since 1976, I also have a history of Fortran, COBOL, PL/I, assembler, and other legacy languages that were never case sensitive (perhaps due to the single case nature of card punches). Today I use modern languages including Visual Basic which preserves case for pleasing appearance, but is not case-sensitive itself (it will correct the case for you in the IDE, which is quite nice). In all my years of programming I have never seen the rationale for making a programming language case sensitive. It simply makes typing it in harder, and mistakes easier, yet we persevere with maintaining it in modern languages like Java. Without making this into a religious war, can someone make the argument of why case-sensitivity in a language is 'a good thing'? And don't confuse this with handling case-sensitive data, which is fine."
It's nice that VB corrects your code in its proprietary IDE, but C/++/Java is used in many different editors/IDEs. The language thus enforces clean code case-wise by being case sensitive.
Browse Slashdot at Funny+5, everything else -5. The only way to sustain it.
One advantage of case-sensitivity of variable names and the like is that it allows ad hoc separations of name spaces.
For example, it is a common practice in C to use ALLCAPS for macro definitions and alllowercase for variable and function names. If adhered to strictly, it means that there won't be any collisions between variable and macro names.
It can be convenient in maths heavy code too, where the use of long variable names quickly makes the code hard to read due to excessive line lengths. Being able to use short upper case names for 'big' objects (eg matrices or operators) and short lower case names for 'small' objects such as scalars matches mathematical convention and keeps equations short and readable. Case sensitivity means that there won't be any accidental collisions between the two sets of objects.
It's certainly not necessary, but it can make life a lot easier. If you don't expect your language to ignore case, then you're unlikely to make case-based errors as a programmer. Especially if you're coming from a mathematical background where 'A' and 'a' rarely refer to the same thing.
I strongly recommend you look at IntelliJ's IDEA editor for java. It will do the case fix if you make a mistake.
Personally I prefer case sensitivity iN ALL LanGUagEs, inCludDinG jAVa bUT AlSo IN eNGlish.
Having had the pleasure of maintaining some Fortran code that was decidedly haphazard when it came to case consistency, all I can say is thank God C and Java are case-sensitive. The only reason languages like Fortran are case-insensitive is because punch cards and many early terminals only had uppercase characters. This enforced a consistency in case, but once terminals with full character sets became common I'm sure legibility of code became an issue.
Relying on an IDE to correct your sloppy coding by enforcing case consistency is a dubious idea. An IDE can have many positive features - syntax highlighting of errors, automatic indenting - but it shouldn't automatically "fix" errors. Sooner or later the IDE will make the wrong decision about how to fix a programmers syntax error, leading to potentially subtle and hard to find bugs.
Chris
I think the biggest reason is style enforcement. The reasoning goes something like this:
1. Case distinction is room for additional information without increasing the length of the text.
2. For the additional information to actually be useful, people have to know what the case distinctions mean.
3. For people to know what the case distinctions mean, there have to be established conventions.
4. Conventions fall apart very quickly if there is no enforcement or verification.
5. It is useful to make the compiler perform some of the verification and/or enforcement -- you're much more likely to notice problems immediately if the problem is caught by the compiler rather than an optional LINT tool.
It is a lot like case sensitivity for English. It really isn't needed, but it sure helps you understand things a lot more easily. You can scan for the start of the next sentence much more quickly if the sentence starts with an uppercase letter and the rest are lowercase. In the same way, you can get a quick sense of what a variable is for by observing its casing, assuming that you are familiar with the casing convention in use.
English teachers force us to use proper spelling, grammar, casing, and punctuation so we can communicate more clearly. Computer language syntax works the same way. The parser/compiler could do a fine job with a much simpler language, and it doesn't really need to be that strict about syntax checking. ("Error: missing semicolon." If it knows there is a missing semicolon, why can't it just pretend the semicolon is there and go on?) The idea is that stricter syntax checking is useful to the original programmer (many syntax errors are also indicative of logic errors or ambiguity) and also to the maintainer who has to make sense out of the code.
So the bottom line is that following coding conventions makes your code more readable and your intent more clear. Case sensitivity is one way the compiler helps you maintain your coding conventions.
Time flies like an arrow. Fruit flies like a banana.
Well, if you prefer hacking non-case-sensitive code, just don't leave your Visual Basic and Windows playground and let adult programmers with a mathematical background work as they did since the computer was invented. If you really want a non-case-sensitive Java, just grab some free, open source Java implementation and modify it to be case insensitive. No one will stop you. But you do remember that Java source code is assumed to be Unicode, do you? And you remember that some Unicode characters are considered to be either upper or lower case, but have not exactly one corresponding lower resp. upper case character, do you? One simple example is the German sz ligature, but there are many more. In France, it is custom to leave out the accent signs on upper case letters, so toLower(toUpper(s)) is not equal to s.
Tux2000
Denken hilft.
> Without making this into a religious war, can someone make the argument
/home).)
> of why case-sensitivity in a language is 'a good thing'?
If you look up "holy war" online and skip over anything having to do with
real-world non-computer-geek religions, you'll find the following classic
examples of holy war materiel: Emacs vs vi, big-endian vs little-endian,
*nix vs non-*nix, CISC vs RISC, and case-sensitive vs case-insensitive.
In short, it's highly a matter of taste. Some people even like to have
case-sensitivity in their filesystems. (Personally, I dislike that and
think that should be optionally possible to turn it off in certain
directory trees (particularly,
Personally, I don't mind case-sensitivity in a language, generally. Perl
is very much case-sensitive, as is elisp, and neither has ever troubled me.
The only time case-sensitivity in a language has really bothered me is in
Inform -- but that was because of the incompatible _changes_ in the case
sensitivity from Inform5 to Inform6, which caused a lot of my code to break.
Now, that said, it is also possible for a language which is case-sensitive
to go far wrong in its use of case by being inconsistent in a way that will
leave you unsure which case is correct sometimes. For example, if a lot of
the ready-made modules/libraries/whatever that you use are not consistent
with one another in their use of case, that would be very bad. In elisp and
Perl, I have not generally found that to be the case. I can't speak for
Java; my attempts to learn Java have largely ended with "Ew, it's like C++".
Cut that out, or I will ship you to Norilsk in a box.
Ok, here's the solution for all the case-challenged intellects out there, who can't seem to grasp that the ability to use both cases does not imply the requirement to do so:
Program with the capslock key on. Occasionally run your code through "tr 'a-z' 'A-Z' and diff that against your existing file, to resolve conflicts. Fix the translated file and work from that, and quit complaining about the fact that a language has features you don't use. There're plenty of languages that were developed on baudot teletypes, so use one of them, if it's such a hardship.
We're using numbers to represent letters, and the only thing relating an uppercase character to its lowercase counterpart is the ascii translation table. If someone is using a DBCS input method for variable names, do you really think the compiler should anglicize the bytes? Or, perhaps you'd like the extra complexity of having to specify localization? Sure, it can be done, but why write around the preferences of fools?
Bottom line is that while you may have a point in cases where the code will only ever be seen by the individual that wrote it in the first place, in cases where the software will go through a full life cycle and eventually become a sustainment system makes readability and understandability an absolute necessity, otherwise you'd never be able to sustain the system with any sense of efficiency.
I hope that this 'nudged' you into getting a clue about writing good code. Cheers.
I have no regrets, this is the only path.
My whole life has been "UNLIMITED BLADE WORKS"
:set ic is your friend.
grep -i is your god.
No you don't. The coding standards say that initial letters are capitalized for all words except the first. If you know that rule, there is nothing to remember for each function name. Unless of course, you're not following the coding standard, but I imagine that you are since your gripe is with that standard.
I'd rather be lucky than good.