Naming Variables

There are two hard problems in computer science; 1. Cache Invalidation 2. Naming Things 3. Off-by-one Errors The guidelines in this video will ease up a third of them. https://www.youtube.com/watch?v=-J3wNP6u5YU
CodeAesthetic
YouTube
Naming Things in Code
It's hard to come up with good names in code, but its also easy to get wrong. By looking at some examples, we can get 80% of the way there. Access to code examples, discord, song names and more at https://www.patreon.com/codeaesthetic 0:00 Introduction 0:31 Variables with a single letter 1:08 Never Abbreviate 2:06 Types in your names 2:36 Units...
11 Replies
Unknown User
Unknown User16mo ago
Message Not Public
Sign In & Join Server To View
WillsterJohnson
WillsterJohnson16mo ago
you're right, abbreviations make it easier for people who know what those abbreviations mean to understand the code. But it makes it significantly harder for those who don't know the abbreviations to understand the code. Unless you can be absolutely certain that everyone who will ever need to edit your code can understand those abbreviations (hint; you can't) then you shouldn't use them. prgmCtx may be perfectly readable to you, so you may think it's totally fine. How about pgmCnt? Those abbreviations are completely valid for "program context", but how do you know the author didn't mean "pagemaker controller"? Likewise, how does a reader of your code know that you didn't mean "pregame ciphertext"? Abbreviated variable names demands not only pre-existing knowledge, but also the correct guess and a general understanding of the file you're reading and it's position within the program. It's a lot easier for everyone to instead embed that information within the code itself, rather than to write out documentation for the code base and expect anyone to bother reading it. It takes very little effort to change prgmCtx to programContext, even for existing projects (F2 in VSCode), it takes a lot of effort for people who's mind is different to yours to expand that abbreviation, especially if it's more esoteric or project-specific. --- All that said, there are times when abbreviation is appropriate. A single-character variable, such as the i in for i in range(20):, tells the reader "this variable is an insignificant incrementor that will go out of scope in a few lines". That's not to say any iterator may be a single character, but incrementors can be. for (const i of myNodeList) is a bad idea, don't call DOM elements i. Likewise, the standard for using CanvasRenderingContext2D is to use const ctx = canvas.getContext("2D"), and sticking to accepted standards is usually a good idea. (this isnt to say that ctx should be used instead of context everywhere, but here it is standardised and therefore is acceptable).
Unknown User
Unknown User16mo ago
Message Not Public
Sign In & Join Server To View
Jochem
Jochem16mo ago
Onboarding time is going to be higher with shittier names, which makes onboarding harder and more expensive. And more expensive again when you haven't touched a codebase in 6 months and need to fix a bug
ErickO
ErickO16mo ago
I'm just here to say I had never in my life seen "program" abbrv. as "prgm" I would not have guessed that
Jochem
Jochem16mo ago
some stuff is fine to abbreviate, I'd say context or elem are potentially acceptable depending on context (lol) but 99% of the time the timesavings of typing ctx instead of con[tab] in any modern IDE are so absolutely minimal, it's not worth the extra cycles it'll take others (including you six months later) trying to figure out what the hell you meant by cc = parseInt(invoice.comp.ccval * ccidx);
ErickO
ErickO16mo ago
I also don't think there's a huge difference between abbreviation and the full word (unless is a big ass word) we don't generally read every letter of a word which is why we have those facebook memes of jumbled up words that you can still read perfectly fine and sometimes don't even notice they're jumbled up this is called Typoglycemia btw
Jochem
Jochem16mo ago
As long as you don't end up with class InvoiceManagerFactoryFactory like good old fashioned corporate Java
Rägnar O'ock
Rägnar O'ock16mo ago
I got DICOMVolumetricImageFactoryInterface to offer as a demonstration of "naming thing is hard" (but at least you know right away that it's an interface for a factory that make volumetric image out of DICOMs (medical image files)) I could have called it DCMVolImgFacI but that would not mean anything to anyone oh and, I want to add "handling floats" as the 4th hard problem of computer science... those are a mess
WillsterJohnson
WillsterJohnson16mo ago
that's a good name given what you have to work with there, but even within the industry I'd say that the top of the doc comment for that class should say DICOM: "Digital Imaging and Communications in Medicine" - standardized biomedical image & metadata protocol. IMO with variable names, the only acronyms you can use without explanation are ones which are part of the language (or in case of a DSL, the specific domain). In JS for example; - DOM is fine; it's part of the language - HTTP is fine; it's intimately related to web technology (and appears in the address bar on every website) - CRUD is not okay; it's a concept from a tangential topic - LTE is not okay; is it a mobile network or a comparison operation?
Rägnar O'ock
Rägnar O'ock16mo ago
In that case DICOM is fine because the whole app is based arround reading this kind of files