Vincent A Saulys' Blog
Always be Consistent with Coding Styles
Tags:
April 10, 2021

With the advent of new, higher level programming languages, code styles have changed and so should programmers.

Looking at something like Assembly, many variables get esoteric names like "whWindow32." This is done for several reasons. Sometimes its for length issues (DOS famously had a 8.3 filename length), sometimes its for legacy requirements (32-bit vs 64-bit), but often its because you need so many variables to do a simple operation. The "old style" generally had you writing with your weird names and then topping it off with a comment to say what this code block did.

; Change disk read and write vectors (INT 37 and INT 38) to go to
; DIRECTREAD and DIRECTWRITE rather than READ and WRITE.
;
    SUB BP,BP
    MOV W,[BP+37*4],DIRECTREAD
    MOV W,[BP+38*4],DIRECTWRITE

    MOV DX,100H
    MOV AH,26       ;Set DMA address
    INT 33
    MOV CX,[6]      ;Get size of segment
    MOV BX,DS       ;Save segment for later

Above is from the MS-DOS 1.25 source code

In context or reading the associated technical documentation, you can probably grok what's going on. But with the advent of higher level programming, this is unnecesary.

Short variable names are incredibly hard to read. You can't tell exactly what something is without needing some extra side notes.

It's instead better to use a very long variable name instead. Most people's monitors are plenty long enough to read code blocks of that length.

This gives a big advantage: no more comments mucking up code blocks. They are still necesary here and there. But eliminating code blocks makes for more compact code that can be scanned easily. If you're typing and rading tens or hundreds of thousands of lines of code everyday, your brain will thank you and you don't need to scroll as much.

While we're on the subject of variable names: keep a consistent structure to this.

Take python, whose internal libraries use the following:

There are, annoying, exceptions here (e.g. string.toLower()) but the fundamental idea usually holds.

I say this as I regularly encounter code where these cases are switched up willy-nilly. It makes for eye strain as I have to check "was this a static function being passed? an object? maybe a variable?" with every passing scan. Keeping to a consistent naming scheme, whichever you want so long as its consistent, helps to alleviate this. That way you can get back to problem solving and pattern recognizing instead of text scrutinizing.

Type checkers and code formatters will not catch these errors so you need to be wary.

Share on...