programming and human factors
by Jeff Atwood
One of the most pernicious problems with C-based languages is that they're case-sensitive. While this decision may have made sense in 1972 when the language was created, one wonders why the sins of Kernighan and Ritchie have been blindly perpetuated for the last thirty-three years.
I realize this is a religious issue. I'm not attempting to change anyone's mind. I'm merely voicing my discontent with the status quo. Thirty plus years later, does case sensitivity still make sense? Julian at OddThinking makes a compelling argument that it doesn't in The Case for Case-Preserving, Case-Insensitivity:
Suppose I declare that "KEANU REEVES interferes with elephants.". Can I claim that I was not libelling the wooden Hollywood actor, purely because I spelt his name in all-caps? Can I claim to a judge that KEANU REEVES was a undeclared identifier and therefore the entire statement was semantically meaningless? Of course not. The English language is flexible enough to recognise that "KEANU" and "Keanu" are the same name. Even mail addressed to "KeAnU rEeVeS" will be delivered to the correct person.If a computer can also disambiguate this accurately, it should do so too. If the software fails to adapt to the similarity of upper- and lower-case, it leads to frustration.
For me, an example of this frustration appears in both Python and PHP. Each of them have the same killer combination: they are case-sensitive with identifiers, but they are scripting language that do not resolve identifiers at parse-time. I consistently fall for the same traps. A distressingly large percentage of my debugging time is spent correcting mistyped identifiers - often not detected until several minutes into a test run. The most common mistyping I make is incorrect capitalisation. Of those, the two most common capitalisation errors I make are: HOlding DOwn THe SHift KEy TOo LOng, and being inconsistent in CamelCasing the term "fileName" (I never did resolve satisfactorily whether it was one word or two!)
However you feel about case sensitivity, the bottom line has to be this: does it cost you productivity? The answer is undeniably yes, as Scott Hanselman notes:
I spend an hour today debugging a possible problem only to notice that "SignOn" != "Signon".If I had a nickel for every time Case-Sensitivity or Case-Insensitivity bit me, I'd have like seven or eight bucks. Seriously.
Moral: Know if whatever you're working on cares about Case, and if it does, make a Post-It to remind you and stick it to your monitor.
There's nothing we can do about existing tools and languages that are case sensitive, but we can make sure we don't perpetuate past mistakes. Unless you have extremely compelling reasons to make something case-sensitive, case insensitivity is a much more human being friendly design choice. Designing software that's easier for machines is questionable at best.
Hi Jeff, you may or may not agree with the response I just posted on my blog, but I've got evidence that case sensitivity can be good. :-)
http://blog.micropledge.com/2007/07/the-case-for-case-sensitivity/
Ben Hoyt on July 17, 2007 8:37 AMOne thing no one should doubt is that case-insensitive is better for beginners. It lowers the amount of errors beginners make, and thus lowers the bar of entry.
Look at all the development environments designed with beginners and non-programmers in mind, and they are case-insensitive: pascal, HTML, SQL, logo and its variants, BASIC and its variants including visual basic, etc. Even the creator of python wanted to change python to be case-insensitive, explicitly because it was a source of errors with beginners, but was rebuffed by some existing python users.
That said, people aren't thinking outside of the box here. It is possible to support both. You can have a compiler that is case-sensitive, but uses case-insensitive matching on failure. It's very simple to implement, I've done it for boo, which is _nearly identical_ to python syntax-wise. It can also check for names that vary by naming style (SomeName vs. some_name). That allows people to get away with a lack of creativity in variable naming:
dog = Dog("Rex")
yet still not have to memorize the exact naming style of some method.
Even that isn't thinking outside of the box enough. Again, look at development environments designed for children and non-programmers to see other ideas, such as the graphical building blocks used in lego mindstorms, scratch (http://scratch.mit.edu/), Labview, Yahoo Pipes, and other recent web 2.0 ides.
Doug on July 18, 2007 10:58 AMDoug, I agree.. a compiler should warn the user that there are two similar variables being used with different case. Languages them selves should not permit case sensitivity, for the same reason Ada does not permit it. Unfortunately even Wirth has designed Modula/Oberon to be case sensitive.. worse yet one must type BEGIN and END reserved words in CAPS LOCK.
L505 on July 24, 2007 8:32 AMCorrection: I agree with doug about people not thinking outside of the box, I still think case insensitivity is nice, and NewDog or DogCast is better than the more confusing dog and Dog.
L505 on July 24, 2007 8:55 AMThe one, and only, situation in which *any* string comparison should be case-sensitive is passwords. The cost of the decision, for example, to make the *nix file system case-sensitive is almost certainly now in the 10s of millions of dollars and increasing every single day. Unacceptably foolish.
Jarmo on August 15, 2007 12:06 PMCase sensitivity is a Good Thing.
First and foremost, it makes Foo and fOO used for the same variable a debugging issue instead of maintenance by a future coder issue.
Second, in some languages, for example Java, Foo and foo are assumed to mean different things. Foo is normally class name, while foo is variable/method name. In some languages, for example Haskell, that is even compiler enforced. In those languages, letting Foo and foo mean different things is a good thing. For example "public void setFoo(Foo foo)" is a frequent pattern in Java code.
Pavel on November 30, 2007 10:51 AMFirst, I'd like to point out VisualAssistX to anyone using Visual Studio. If you type pCharacter.gchar it will suggest getChar(). (See shorthand: http://www.wholetomato.com/products/features/members.asp )
Also, I'd like to ask if _anyone_ here would submit code with two different spellings of a variable name and not be embarrassed about it later. (I'm actually curious.)
Jeff, if you had an IDE that told you you spelled 'console' incorrectly, would that make you happy?
And finally, some anecdotal evidence of case-sensitivity being helpful:
A friend of a guy I think I know was maintaining some code. There was a function called diveRunDo. However, since he was using a case-insensitive language, when a coworker called that function but used diverUndo, the compiler didn't complain. So my friend spent hours trying to figure out why the diver's last action wasn't being undone.
So that's not true, but I can imagine many such problems.
Case sensitivity lets the worst instincts of developers run wild.
I would say that lax rules let the worst instincts run wild. Really, instead of case insensitivity, a better solution would be something like what Maciek suggested: The compiler complains when you use variables that only differ by case.
I see enough spelling mistakes in comments (even though VS highlights them), I don't need to see them in variables. ANd don'T improper CAPITALs bother yoU?
-David
David on December 3, 2007 1:53 AMTypos aside, I think this problem pretty much goes away when you come up with a variable naming convention and stick with it.
I've been bitten by similar identifier problems in scripting languages, but to my knowledge, it was never a case thing. It was always something like "varlist" versus "var-list", or changing the name of a variable and missing one accidentally (oops, didn't do a global search and replace.) Caps have never bugged me.
Evan DeMond on December 3, 2007 7:06 AMShould be obvious:
One place the case-sensitivity problem can be tackled is in the IDE or editor.
I know this sounds almost off-topic, but how feasible does changing the syntax conventions of languages look when millions of lines of code are running in production use across the world and your new version comes as an upgrade?
IMO, For all practical purposes, we can *do* almost nothing about these time-sinks. Requiring people to readjust their habits and thinking, which they've comfortably lived with for years? It's easier to become Bill Gates.
...
Or is it The System's way of ensuring that we don't reach the best possible language syntax ever? That we constantly keep making mistakes and *then* repairing them when we find them?
All humans, after all...
(PS: Sorry if I didn't read a similar comment above - there's probably a hundred of them...)
Well, probably should not only FooBar, foobar, and FOOBAR be the same thing, but also FOO_BAR and foo-bar?
Andreas Krey on December 3, 2007 12:07 PMi'll actually often use the same name with different capitalisation for multiple things. Most notably classes and variables which hold instantiations of those classes.
For example, in Javascript:
function Client() { }
(yes, this is how you make a class in JS)
var client = new Client();
because I always use UpperCamelCase for classes and lowerCamelCase for variables, I don't have to resort to vUsing adjHungarian nNotation, or my other favourite method when not using a case-sensitive language:
var myClient = new Client(); // or,
var theClient = new Client();
Writing KEANU REEVES in english rather than Keanu Reeves is just as incorrect a use of the language as cap mistakes are in C. The difference is that the compiler for the english language (or any other human language), the human mind, is insanely much more powerful than any compiler for a computer language, and thus can figure such ambiguities out, just as it can decode spelling mistakes, incorrect grammar, understand accents when compiling spoken languages etc. This doesn't mean that it's right to type kEanu ReeVes, just that the compiler catches the mistake and corrects it automatically.
Jens J on December 7, 2007 4:31 AM[quote]
Writing KEANU REEVES in english rather than Keanu Reeves is just as incorrect a use of the language as cap mistakes are in C. The difference is that the compiler for the english language (or any other human language), the human mind, is insanely much more powerful than any compiler for a computer language, and thus can figure such ambiguities out, just as it can decode spelling mistakes, incorrect grammar, understand accents when compiling spoken languages etc. This doesn't mean that it's right to type kEanu ReeVes, just that the compiler catches the mistake and corrects it automatically.
[/quote]
http://rx-review.com/
perfect generics - http://perfectgenerics.info/
I read through most of the above posts...
What surprised me with this particular example:
'I spend an hour today debugging a possible problem only to notice that "SignOn" != "Signon".'
Is that any decent tool would alert the coder to his mistake unless he had used both SignOn and Signon as variable names, in which case, thats the programmer's own fault for using variables with similar names. Certainly should not have taken an hour to notice...
As much as case sensitivity causes a problem it can at least be worked around with a good compiler/interpreter. I totally agree that any new language should not be case sensitive though... I struggle to think of any reasons why that is a good feature for the user, it just makes things easier on the developer /sometimes/... after all, almost every major language comes with some kind of case-insensitive comparison in its libraries (even the notoriously unfriendly C++ has "stricmp" and friends).
Jheriko on January 2, 2008 4:59 AMIn my opinion case sensitive source code is (much) better because it is easier to read.
Having the same identifier always written with the same 'casing shape' helps me to spot its repetitions in a page of code quickly: actually spotting the shape of the word before I even read it.
I find it takes longer to read code if the casing always changes.
Look at
theNumber += 3;
THENUMBER = thenumber / 2;
TheNumBer = function(THENUMBER);
And
theNumber += 3;
theNumber = theNumber / 2;
theNumber = function(theNumber);
In the second example it's more obvious to me that just one variable is involved in the computation.
Case sensitivity is useful in the same way as indenting, aligning and using blank lines might be: it helps readability (not as much as correct indentation of course).
Of course writing in a case sensitive language takes (a little bit) more time but since we read source code more often than we write it I believe it is a performance improvement after all and I like it enforced by the compiler.
So you wanted a real world example in regard with case sensitivity being helpful rather than just spoiling all the fun?
Well, here's one. Imagine that there's some Matrix class:
class Matrix
{
//... more stuff here...
public:
void printOnScreen() const;
private:
size_t x, y; // -- attention!
std::vectorint cellVec;
};
//- simple printing to console (with formating)
void Matrix::printOnScreen() const
{
//- now look at the loop variables...
for(size_t Y = 0; Yy; ++Y) {
for(size_t X = 0; Xx; ++X) {
std::coutcellVec[X+Y*x];
}
std::coutstd::endl;
}
}
It's clearly seen to me that in this context Y != y X != x
They are not the same. What would you propose in a case insensitive environment?
1. using "size_t _x" or "size_t x_" or "size_t xx" or whatever as loop variables?
2. using "this-x" and "this-y"?
3. renaming class members to free "x" and "y" identifiers for loop usage?
4. your solution here...
I'd say that anything would be less readable than the example above.
But it's just me...
The company I work for has a procedure in place where any code changed by one developer must be checked by another. This is normally done by comparing the code before changes to the code after changes using a diff tool. VB, with it's code insensitivity, drives me insane everytime I have to do one of these comparisons. There's always a bunch of variables that have changed case (usually because the developer accidently changed the case of one instance and the IDE decided to help out and changed the rest).
Now, I could change the diff tool to ignore case, but then strings presented to the user may have changed, so users end up with badly Capitalised sentences (which drives my manager insane). So, VB's case insensitivity is a right PITA, which C# gives me no problems at all.
NakedProgrammer on January 11, 2008 9:03 AMI think his whole whining about case sensitivity is pretty silly.
As for scripting, people are not more prone to "mis-case" a name string than mis-spell it in other fashions, especially if he or she adhers to sound naming conventions, like "all english words in a name start with an uppercase letter".
So you could argue that not only case sensitivity should go, but also any sort of precise spelling. Yeah, let the compiler guess what is closes to the declared names, right? Would be so cool.
No it woulnd't, it would be ambiguous shite, just like case insensitivity.
I think we should not revert our languages to pre-stoneage behaviour, especially not for such silly reasons.
How about this:
1) demand programmers/scripters to adhere to sound naming conventions (consistent inside company)
2) use tools to check every script's strings against the declarations for ANY sort of misspelling. If there's a string found that's not declared, this is a syntax error !
The fact that scripting works so much with strings to call things makes these into somewhat of a language feature that should be checked by the language for correctness...
If no such language or external tools are available, make them yourself, damn it, it's a piece of cake.
I prefer my compiler to not attempt to mangle isLand() to Island() or vice versa, depending on which declaration came first, thank you very much. And using a camel naming convention without underscores makes me more efficient, because it helps wrong things to look wrong, just like Apps Hungarian notation does, so I will spot them early and fix them early. And even if I do fail to spot the problems, the compiler will barf on it instead of silently incorporating the problem into the runtime, making for an earlier failure (which is also a Good Thing). Sure, I could circumvent this by not using case, but rather underscores and whatnot, but case is in my opinion better precisely because it's natural: I can identify/separate words based on capitalization faster than I can spot underscoring differences, and I still see them as a single block of text and not several pieces connected by something else.
In any case, whatever your preferences may be: you're just a short lowercasing/case-translating script away from following your own conventions regardless of the compiler's/interpreter's needs, so there's no need to be aggressive about it.
For speed I usually cut n' paste identifers in C++/.net/Java so very rarely do I ever have case sensitivity problems - and anytime i do I get compiler errors. Parsed languages will catch most such errors unless they decide to define/allocate a misspelled varaible as a new one and use it wihtout warning, review your choice of coding language if this is problem. Humans are sloppy granted - and should be allowed some slack, but programming should still be a matter of precision so I see no major reason why case-sensitivity should degrade coding efficiency unless one is being ruthlessly sloppy.
You'll be happier to read neat consistent, properly indented, spaced and commented code (with hungarian notation or similar) rather than a mess of mixed casing and multiple naming paradigms.
Finally if you have time to worry about case-sensitivity vs coding efficiency then obviously more important things like your software design and algorithm efficiency must be impeccable. Otherwise worry about that first!
daz on January 31, 2008 4:21 AM"In my opinion case sensitive source code is (much) better because it is easier to read. Having the same identifier always written with the same 'casing shape' helps me to spot its repetitions in a page of code quickly: actually spotting the shape of the word before I even read it."
My IDE (VS.NE) automatically fixes the case in my code to match the declaration at dev time and I get the same benefit.
I guess it is like those woodworkers who insist on chiseling their own mortises, it might not be as clean, but at least it takes twice as long!
JohnFx on February 22, 2008 2:39 AMI like the isLand() - Island() comparison. Also, here's one adapted from an episode of Squidbillies...
Therapist - theRapist
Hmm. Perhaps case sensitivity is a good thing after all. I wouldn't want to get those two confused.
RWW on March 14, 2008 4:05 AM"Well, funny I've never come across a bug related to case sensitivity !
I even find it easier to read initNightRunRun1 than initnightrunrun1, don't you ?
I'd even be happy to have the language force me use initNightRunRun1 everywhere after I've defined it !"
If C# were case insensitive why wouldn't I still be able to use 'initNightRunRun1' ? And in the IDE, if we tried to type initnightrunrun1 after the original 'initNightRunRun1' was used then intellisense should correct it. So, I agree that the IDE should help keep the variable names pretty and enforce only one version ( case combination ) of that variable name. And why not add that as an option to Visual Studio ? What could it hurt ?
But why oh why does it allow something like the following ?
foreach (Order order in orders)
When I see this it makes me cringe. Talk about sloppy coding. If you're insistent on using the name 'order' in the first two variables then why not prefix it with something meaningful instead of using case ?
Tycho_Brahe on April 23, 2008 2:27 AMI like case sensative. We use lowercase to denote private variables and uppercase to denote public ones. Makes it a lot easier to keep track of things without having to modify the names themselves.
Kris on May 20, 2008 2:07 AMI love case sensitivity.
I do.
ilan on May 30, 2008 1:54 PMI'm not agree with it that case insensitivity is a much more human being friendly design choice. I think that case insensitivity is NOT much more human friendly design choice. I wrote about this in my friend's blog on http://detoxmed.com. I think that's be useful.
Brian on June 6, 2008 2:19 AM@Kris: We use lowercase to denote private variables and uppercase to denote public ones.
But you can still do that, even in a case insensitive language. You just can't use the same word. Which isn't particularly valuable in the first place.
As for Python and case sensivity - that's why we all have that nice autocompletion feature in our code editors.
I usually only write a word completly once, all the rest instances are autocompleted after first 3-4 letters I write. When I misspelled these first letters something wrong or nothing at all will show instead, so I will notice this.
Autocompletion is IMHO the single most important text editor feature, even more important than syntax higlighting.
PS. when writing graphic/physic code in C++ I often name my variables X,Y,Z when refering to world coordinates, and x,y,z when refering to object coordinates, it also aplies to other short names mostly used in numerical algorithms. I can't persuade myself to use normal camelCase convention there, it would make my nice equation 4 time as long, and I would have to break it into many lines. It's like in math - differenting variables by case is sometimes useful, mainly when there is some constant relation between every big and small case variable.
odrzut on July 8, 2008 3:34 AMMany posters are still confusing case sensitivity with case preservation, they are NOT the same thing. Case preserving means that something kept using the capitalization as it was typed. Case insensitive means that case is not relevant when comparing a string (e.g. a variable name, class name, etc).
In a case preserving system, you can use CamelCasing (or camelCasing), if the system is case insensitive, then Foo=foo, but in a case sensitive system Foo != foo.
People read mixed case text faster and more accurately than all upper or all lower case, there have been numerous studies that demonstrate that (you can google them if you want). This alone is a very strong reason for case preservation. Case preservation also provides clarity, ExpertsExchange clearly has a different connotation to the reader than ExpertSexChange and either is much clearer than expertsexchange. Case preservation is a great thing, I'm very much in favor it of.
Using only case to differentiate variable scoping is absolutely unacceptable. I don't have as big an objection to using it to distinguish an instance vs. a class, but I do think it's a poor practice.
As I mentioned in a previous post, case sensitivity is sometimes necessary and appropriate, however, I'm opposed to case sensitivity in most instances.
In fact, for clarity, I'm going to stop using the terms case sensitive and case insensitive and start using case dependent and case independent.
Variable, class, function, procedure names should not be case dependent. Program names, command line parameters, and program input should not be case dependent, EXCEPT when necessary and appropriate.
In a well designed case preserving, case independent system with an editor that provides auto-completion, you get the best of both. All variable/function/procedure/class name is converted so that all instances have the same case. It is preferable that all instances are converted to use the case used when the object was declared or defined, that way the developer only has to worry about getting the case correct one time, and all other instances will be converted to match that one.
The only thing you can't do in that environment is use ONLY case to differentiate the scope (or differentiate between an instance and a class). For instance, you can't use var client = new Client You can still use case to differentiate a class, instance, or scope, but you can't use ONLY case. For example, you can use var curClient = new Client. You can also use Hungarian notation.
This allows for writing very readable code that is more maintainable by another developer. It also creates code that is portable to another system/language while minimizing the problems of different variable scoping rules, syntax differences, etc.
Code is read more than it is written.
And a case sensitive language forces you preserve the case.
A variable named greenHorse is more readable than GREENHORSE,greenhorse or GrEeNhOrSe,...
And while I know you can just use case preservation in a case insensitive language, it is my experience that unless it is enforced(like with a case sensitive language) People just won't do it.
PS. the argument that an IDE like VisualStudio will autocorrect case preservation in a language like VB.NET is void, since it will also autocomplete case sensitive variables in C#/C++. thereby avoiding the differentCaseDebuggingProblem.
Rebel with a Cause on August 25, 2008 3:50 AMIMHO case sensitivity should not matter to the programmer. I believe it is part of good coding style to type identifiers in a consistent manner whether or not the language in question is case-aware.
Would you really feel happy with a code block that refers to both FOOBar and fooBaR?
I got into the habit of assuming that the language I'm writing in is case sensitive. I only recently realized that PHP's functions are not case sensitive! I can't remember the last time that I actually had an error because of case sensitivity, it has become a way of coding for me.
Jrgns on February 13, 2009 10:59 AMPeople who like case insensitive languages are just lazy.
How is cabbage equal to CABBAGE atall? Doesn't make sense!
As a PL/SQL programmer I can say that
v_person_name = V_PERSON_NAME
but
'Smith' 'smith'.
Variables need to be parsed only at compile time, so no worries for tiny performance penalties there. Person names, OTOH, need to be compared millions of times a day. So you trim every fraction of a second where you can.
oca on April 1, 2009 3:45 AMMany years on and this argument still hasn't been settled... I doubt it ever will be but here is my 5c worth (cos our government stopped making 2c a long time ago):
Using case sensitivity to refer to different variables is just plain stupid. I program primarily in C# but the only time I (or anybody I have ever worked with) make use of differing case to name things is in the case of a property and it's backing store; after all, they are two different ways to expose the same data (external and internal respectively, when used properly). That gives a clear indication that they are related without having to add on wasteful prefixes.
I agree with Wayne Kroots, casing is simply a matter of style, the consistency of which should not depend on the language. Do whatever makes the code more readable, even if that means maintaining proper casing in languages like VB.
As for Scott Hanselman's case, it is unclear if his problem was casing of the variables themselves or the string values they represented. Any language should be able to perform both case sensitive and insensitive string comparisons, it's up the programmer to decide when and how to use which.
Finally, to Jeff Atwood, you kept saying you were only able to find documented cases of case sensitivity hindering developer performance. Something all of us as programmers should be aware of (based solely on user feedback if nothing else) is that people are quick to complain when something doesn't work the way they expected, but much (much, much, much, muuuuuuuuuuuuuuuuuch) slower to praise when it does. With that in mind, don't expect people to blog about how case sensitivity just saved them hours of debugging (most programmers will either go home early or find something else to code).
Ph03n1X
Glorified Typist
Earth
P.S. Got tired of reading all the comments so I stopped after about 30 and jumped to the bottom, I'm very sorry if I've repeated anything said before ;)
Ph03n1X on April 20, 2009 2:16 AMI think having a case-sensitive language ENCOURAGES people to write poor code.
Const SHOESIZE = 9
Class ShoeSize
ShoeSize.shoesize
call function shoeSize(SHOEsize)
{
int ShoeSIZE = 10
return ShoeSize
}
Duh. You couldn't think of a better variable name than ShoeSize for the different purposes???? There a billion different words you could use... but you choose to just keep using ShoeSize instead?
Susan on April 22, 2009 1:23 PMI can't believe I just read two years worth of comments saying that case insensitivity leads to hard to read code. Just because a language is not case sensitive, doesn't mean that it won't let you use variables with a casing convention that conveys meaning.
Case preservation is what creates readable code, not case sensitivity. I write VB.Net every day and we have strict case conventions. We catch violations through code reviews just like everyone else does. Writing in C# doesn't automatically cause developers to adhere to sane case conventions.
There is no case, other than using case to distinguish between variables, where an identical casing convention cannot be followed in a case insensitive language. You can write C# in all lowercase if that floats your boat (except for calls to the framework). You'd be just as much of an idiot to do it in C# as VB.
Let me repeat -- the only case where case sensitivity has an actual end-effect is the where two variables are distinguished only by case. Since this is a practice not recommended by Microsoft, there is actually no likely case where there will be a functional difference. Also, since VB is case-preserving, there is no case convention that is not allowed or not preserved (other than the affore mentioned not recommended practice).
The only difference is that a case typo is auto-fixed in the VB IDE and caught by the compiler in C#. If you make a legitimate typing mistake in either language, it won't compile. Learn ctrl-space and you will never make either a casing or a typing mistake. The only reason case insensitivity hasn't been removed from modern compiled languages is that is pretty much doesn't matter any more. Since case sensitivity has traditionally been there in C type languages and removing it will cause a lot of code to not be directly reusable, the minimal costs of changing it outweigh the almost unmeasurably small benefits of getting rid of it.
Jaime on May 20, 2009 7:46 AMit makes no sense.
but yes, I guess it is a religious issue as the comments I am getting here http://stackoverflow.com/questions/895423/case-sensitive-vs-insensitive-syntax are not to the point, but with lots of emotions.
What is needed is case CONSISTENCY.
Give me a call about your C/PHP/Python program and I tell you by voice why case-sensitivity is a BAD-THING. I don't speak in case!
"You need to change your code to CasE, upper-C, lower-a,
lower-s, upper-E".
Case conventions are useful but not for distinguishing namespaces. Namespace checks should be done in a case-insensitive way so I can't have camelCase, CAMELCASE, camelcase, Camelcase all having different semantic uses.
Lummo on June 26, 2009 3:06 AMThis is why Visual Basic .NET doesn't include such little interferences.
The only good thing, I guess, is that the Visual C# compiler is background, so it can catch the erroneous code before you actually debug it.
I find case sensitivity useful for distinguishing between classes and generic members of them; if I only need one object to be derived from a class, then it makes sense to name it similarly. Other than that, I don't think it should be ingrained into the language's keywords. What is the difference between "this" and "This", anyway?
Adam on July 11, 2009 9:37 AM@matt on December 6, 2005 1:23 PM : [...] «You've got the most important case against case insensitivity there is... consistency. What more do you need?»
What about:
* IntegerDaysOld
* IntegerDaySold
?
LOL
I don't think that Jeff is looking for real empirical studies.
Can anyone even come up with an anecdote where case-sensitivity was helpful while programming? Come on, even a friend-of-a-friend.
Bill Tomlinson on February 6, 2010 9:47 PMI don't remember having any problem with case sensitivity. The only spelling-related issues I can think of that caused me debugging problems were in languages like Bash and PHP and they were, most of the time, typos, not bad use of upper/lowercase.
I see your point about case-insensitiveness being more human-friendly but I think that these problems are caused either by not using the right tools or not having a clear style policy.
Also, call me a fetishits, but my eyes bleed when I work with code with inconsistent style conventions. I can't stand code which uses a different convention for each line and, of course, things like 'KEanu_reVeS' and then 'keaNureves' will make my head implode.
Piratbey on February 26, 2010 5:52 PMI'm gonna take the other side of this religious debate.
I'm against anything that lets or encourages coders to be sloppy. Thus letting developers get away with coding a variable or method with 3 or 4 different case spellings is IMHO a very bad thing.
I would extend this languages that allow method calls with "optional" brackets,... JavaScript's semi-colon ";" line endings are optional (except when they bork your code),... and languages that can't decide how they want to format their API (I'm looking in your direction PHP! (is it camelCase or underscore_delimited or what))
With a special honorable mention to languages that promote:
"On Error Resume Next" because blindly ignoring errors seems to indicate either the API is not stable or in need of a try/catch/finally concept.
Hi All, I've just started to find out more about why use case-sensitive and trying to search if there is any benefits in formatting my iMac to a case-sensitive system till I happen to read the post here which took me a few hours reading starting from the early post in 2005.
Though in the end is totally different topic that I'm looking for but someone has been asking in the post about what is the real benefits for case and non-case issue which makes me read more to find out why is there such a rule?
Well after reading the debates on how programming should or should not and the history, is kind of interesting. But mostly are referring to who lay the rule 1st and should it be left out so that programmers can have a better way in writing it faster or easier in order to save time. When time = money in some cases.
Till now non did come up with the reason which I too is quite interested to know the reason behind.
This is my point of view if it make any sense here. I'm not against both way in writing the programs whether case or no case cause I'm not a programmer. Maybe you might just say get out of here since I know nuts. But I think in terms of cost back then when you write a code on a x86 machine compare to now where space is no longer an issue. Now machine are so powerful where you just spend a few $ to get XX Gb of rams or XX Tera of harddisk space.
Maybe during that era in order to save the hardware space which is very very costly back then, the only way is to reduce your language to the minimum characters as short and precise as possible. Now example you key "Horse","horse" to describe 2 different items in a program, and rather in non-case you will have to write "horse1" and "horse2" since you can't file the same name and the list just get longer since you have to describe more so that it doesn't repeat the same name as the file system doesn't allow.
So it took you maybe 50Mb to complete the whole program and maybe with case-sensitive you only need 25Mb?? Back then space is money. Though now space is no longer an issue to most people but don't you think is better to have short and precise program to read rather then compare a long list of english composition which is of course easy for you to key on a non-case environment.
So maybe is it that why nowadays applications/games are getting so big in file size.??
Just a theory not sure if it make sense.
Keith on January 15, 2011 12:11 AMI JUST TYPE EVERYTHING IN ALL CAPS, ALL OF THE TIME.
WORKS FOR ME.
James Knox-Davies on July 31, 2011 6:22 PM
We wouldn't have this problem if computers now are able to catch these errors at parse-time, to correct the mistakes we had 40 yrs ago.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |