Skip to content

Case Sensitivity In Source Code

In case it's not clear from my moniker, in the world of software development Delphi is my preferred weapon of choice and if you're not familiar with it (you should be), the underlying language is Pascal. I've been using Pascal for over 30 years. In this time of COVID-19 lockdowns I've been using my time to learn Typescript, brush up on modern Javascript and familiarise myself with the Node.js ecosystem.

It's been both a rewarding and incredibly frustrating experience (more on the frustrations will be forthcoming as I do plan on an in-depth project post-mortem), but right now I need to ask this question....

Who on God's great earth felt it was a good idea to make any software source code case sensitive?

I've thought about this a great deal in the last few weeks as my casing is sometimes lazy particularly when I'm in the zone and really, when working in Delphi, I only look at it from a source code aesthetics perspective... if... big if these days, but... if someone else looked at this source code what would they think? Would it be "they couldn't be arsed, look at the lazy formatting and casing" or "they spent the time to make it look nice and readable" (in my view the later is the mark of someone who has had the pleasure of working on someone else's code that was less than stellar). myVariable, MYVARIABLE, MyVaRiAbLe... it doesn't matter, they all mean the same to the compiler and that's brilliant, but it looks less than pleasing when you read it.

Compare and contrast that with Typescript (and by extension Javascript), C, C++, C# and countless others... they are all different variable names referring to distinct items.

Why??? It's Just Plain Wrong!

First up, code obfuscation... lets talk about intended obfuscation first. It allows people to obfuscate code by having a plethora of variables of the same name with slightly different casing (I've worked for a place where a contractor did this... he used the same name in multiple places with slight case variation and it made maintenance of the code an absolute nightmare, especially for the uninitiated).

In English... aside from grammatical inferences that can be drawn from capitalisation.. brown = BROWN = BrOwN = bRoWn... You get the picture... the number or position of capital letters has no bearing, except as mentioned, the grammatical inference we get from seeing Brown where one might sensibly conclude it's use is no longer that of an adjective but is instead a name.

Unintended obfuscation is in my view more a side effect of the fact that I can, if I choose, have two variables called loop.... loop and Loop. When perhaps a better choice of names would be itemLoop and propLoop for example.

Remove case sensitivity and suddenly you force developers to provide meaningful variation in their naming, which in my opinion, will result in more meaningful code. Not just for the next poor sod who has to work on your code but for you when in 10+ years you dig up an old project for posterity (which happened to me when I resurrected The Outer Reaches - The Second Beginning and I realised just how poor the code quality was). Yes, you could have loop1 and loop2 but in my opinion this is a sign of one of two things... the aforementioned lack of experience in maintaining existing projects or the indication that someone just doesn't give a dam and if they were plastering your house they would leave it with a surface finish akin to that of the moon.

This has cost me many hours of screwing around, particularly as (unless I've made a fundamental mistake in my VS code setup, which is entirely possible given my Typescript noobie ranking) I can't stick a breakpoint in a Typescript application running on Node.js (not using ts-node) in any file other than my main script (big pain in the ass - if anyone may be able to explain why and help me fix it, hit me up). The main culprit for my pain… cannot read property X of undefined, the main cause of which was typically a casing issue.

It's far too late to save Javascript and Typescript as removing case sensitivity at this stage would break many millions of projects I'm sure, but if by chance you ever design a language... please... I beg of you... don't make it case sensitive. After 20+ years in the software trade I can think of no logical benefit of doing so, but I do ponder how many thousands (possibly millions) of hours have been wasted debugging code only to find it was an incorrectly capitalised variable name that was the root cause, and the worst thing is this type of error kind of blends in with the background.

If of course you're one of the people who have made this decision in PHP, C, C++, Ruby, Javascript, Java, Typescript etc. I'd love to know the reasoning behind it. Coming from a world of Pascal where casing means nothing I just don't get it. I understand it may have something to do with the case sensitivity of the Unix OS on which many things were born, but why choose to carry that through into a language? Performance reasons in what, in many cases, were/are run time interpreted languages? That's the only reason I can come up.

And on that note... back to being careful with my casing. Enjoy and stay safe in this weird world 😄

Comments