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, ;Get size of segment MOV BX,DS ;Save segment for later
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:
CamelCaseWithUppercaseFirstLetterfor class names
camelCaseWithLowercaseFirstLetterfor instantiated objects
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.