IF is not the same as if, the variable X is not x, etc.I argue they should not be. Consistency of coding style among practitioners is a useful and beautiful thing. If some programers write
Switch, others write
switch, and still others write
SWITCH, then code begins to get messy and too individualized. We're not writing novels; we're writing code. Precision and consistency matter.
The standard story I tell in this case is the Mervin Story. Back when I was a fledgling C hacker, Modula 2 had just come out. I programmed probably less than 50,000 lines of code in it and then gave it up as fun but ultimately useless. In evolving Pascal into Modula, Nicholas Worth removed everything that was useful from Pascal, empahsized the annoying strictness of Pascal, and introduced more annoying useless things like mandatory upper-case keywords. But Mervin fell in love with Module 2 so much that he starting writing C code that included a suspicious header file
modula.h. And his C code stopped resembling C and started to look suspiciously like Modula. Sure enough, when we peaked into
modula.h we found dozens of lines of preprocessor macros that effectively introduced a new set of syntactic conventions on the language. Mervin's code was always harder to maintain because the maintainer had to get familiar with the unholy union of syntax that was "his" version of C. Hence the fundamental rule of macros: thou shalt not use macros to redefine the syntax of the language. No one liked Mervin much anyway.
The problem with case-sensitivity for programming is that there is no consistent philosophy. Some argue that all tokens should be case-sensitive. Others argue that keywords and identifiers should follow different case-sensitivity rules. Still others argue that there should be no case-sensitivity at all anywhere.
C is strictly case-sensitive. SQL is case-sensitive for identifiers but not keywords. Fortran historically does not distinguish the case of identifiers, but some dialects respect case in keywords; still Fortran programmers prefer upper-case keywords just to be on the safe side. There is no rhyme or reason across the community what proper capitlization
should be.
Personally I think it would be a wonderful thing to inflect on camel-case evangelists to make them all work in Fortran where
thisFunc and
ThisFunc aren't different names. But I'm not sure allowing interchangeable case is overall a good thing. Keeping code human-readable is far more important than many in the industry seem to realize.
Add implicit declarations (i.e., you don't have to declare a variable before you use it) and you have a recipe for chaos.Rampant implicit declaration is already a recipe for chaos and should be eschewed. Fortran had implicit declaration, but only in a very limited way. If you didn't declare a variable, and its name started with one of the letters
I through
N (the first two letters of the word
integer and the most commonly used ephemeral subscription variables) it was implicitly delcared as an integer, otherwise it was implicitly declared as a real number. Fortran is still a strongly- and statically-typed language, so there's a limit to how much of your leg gets blown off when you shoot yourself in the foot that way.
Implicit declaration coupled with dynamic weak typing in more modern languages is a recipe for unproductive programming. If in one case you type
Receiver and in another case you fumble-finger it and type
Reciever, implicit declaration and dynamic-typing means you'll spend forever figuring out why your program is broken: the interpreter will happily accept that symbol and give it whatever default value is appropriate for the type suggested by that context. A statically-typed language requires annoying implicit conversion at each necessary step, but at least the interpreter helps you out of this frequent typographical jam by saying, "Um, I've never seen this symbol before in your program, and it's being used in a context that suggests I should have." Very helpful, and very respectful of the programmer's time.
Fortran got it right. It requires you to declare variables that have complex and significant meaning, while avoiding cluttering up the declarations with ephemeral crap whose meaning is clear in the context.
Of course Fortran is guilty of the infamous NASA do-loop bug. That was
DO 500 I=1. 100
C Some important stuff.
500 CONTINUE
The bug is hard to find. It's the punctuation in the first line. Because early Fortran didn't respect white space, the compiler interpreted it not as "peform the operations up until line 500 while iterating variable I from 1 to 100 inclusive," but rather as
DO500I=1.100
which means "implicitly declare the variable DO500I as a real number and assign it the value 1.1." Yikes. According to legend, code like that was lurking in human-rated launch pad routines.
I truly think that K&R were too lazy to add case-insensitivity to their original C parser.Any evidence for this? I ask not to rake you over the coals, but because this is an ongoing question in programming morphology. Since many modern languages take their syntax cues from C, understanding its historical roots is important to knowing what to keep and what to evolve.
The most common reason given for C's case-sensitivity is efficiency at compilation time. A compiler whose tokenizer has to sift through various spellings cannot be made as fast and correct as one that respects case. While that is less concerning to modern programmers, it was an issue for Kernighan and Richie, who understandably wanted to minimize compile-run-evaluate cycle time when compilation took many seconds.
But I find no documentary evidence for that; it's simply a reasonable conclusion based on known circumstances. There doesn't seem to be any reason to suppose that's what K and R were thinking.
More likely they were case-sensitive because it didn't occur to them to be anything else. When I learned Fortran it didn't occur to me to write in anything other than upper case because that was the only case available. And so when lower case was introduced, it was for string data only. No one really considered whether we should be writing the language itself in lower case.
And object-oriented programming is very useful. But it can also be the latest incarnation of spaghetti code, if you're not careful.A disease that afflicts a great deal of Java code being written and passed around today. A class hierarchy more than about 4 levels deep is too deep to be kept meaningfully in the programmer's mind, and hopelessly opaque to a newcomer. Java's object model and its requirement that the object model appear in every program leads to code that could have been better organized.
Comments in the code are your best friends!That they are, but not as a substitute for clearly-written code.
Maybe for some people
$0 =~ s!.*/!!; is instantly synonymous with "strip the leading directory path elements from the as-invoked command name," but not to me. (At least I
think that's what that does.) If someone wants to get all concise in my face, I can respond with a +2 stream of APL that, in four symbols, can solve a matrix, match an array of regular expressions, change the oil in your car, and give you sound financial advice. Of course finding a keyboard to type it on is the real trick these days, but the point remains that being able to express complexity in fewer and fewer syllables is not always the sustainable thing to do.
There are big differences between computer programming, computer science, and software engineering. The latter requires being profitable and sustainable, not just clever. And so when one is in the business of software engineering, one must write clear code that does what is expected of it, in the language best suited for the task.
