Lesson 1: Variable Names

Variable names are the number 1 advantage we have over every other science.

If your code is clean, people don't need to know how to code in order to read your code. The average person will see a function, an equation, and some variable names. These are all context clues for the reader; They provide just enough information to understand what the code does for the program as a whole.

Having good variable names can eliminate the need for some comments.

It might seem that "everyone knows what r is", but do they? Maybe, but reynolds number is Re. Refractive index is n (for some reason). The letter K is used for basically every constant in the book (dielectric constant, constant of proportionality, coulomb's constant). I do advocate for calling a variable c if it's just a constant, but if it has a name, it's much better to spell it out than to have to explain it later.

We might have gone a little overboard saying the units. If you have a constant that is just a constant, go ahead and use c or g or e, because the only thing to explain is that it's just some constant variable, which is a given.

"Some number" variables extend past constants. The most famous ones are i, k, and k. If your for loop

holds some significance, go ahead and name it.

Otherwise, don't.

We clearly that i is a loop counter, and that j is a loop counter. It's just standard convention that if we don't specifiy anything else, the variable is exactly what we think it is, a variable.

Naming Conventions

Naming conventions can be tricky, especially when trying to teach. When you write an example, people might think that there is a naming convention for a variable when there is none. This is where I use my favorite naming non-convention:

bruh

This may look like we're making it less readable, but for examples, that's sometimes ok. Number, add, and result can all be keywords in some programming languages. Sometimes people think that you are required to name your variable number in order to make it a number. The advantage of bruh is that there is no way that a programming language would have some

named bruh. This lets you more effectively communicate your intentions to other teammates (or AIs) that the variable bruh can be named literally anything without any repercussions.

Types

Some people like to include their types in their variables. Some use i d f b p prefixes like bBruh to denote type. If you want to know what those letters mean, I won't tell you because I'd rather see you writhe in your own miscomfort. That's how other people feel when trying to read that code.

A lot of people share their hatred for Hungarian Notation. Types normally aren't that important, and you can infer them from looking at how the variables are used. If you are following the rules of variable proximity, it shouldn't be too hard to look up what the type of a variable is. Ideally you shouldn't have to scroll to find that information out. Plus, if you don't know the variable name, you'd need to find where it's defined anyways and that will tell you the type too.

So why bother?

Some people feel it is nessesary for variables that can't follow variable proximity. Some variables have to be global (or at least in a namespace), or in a different file, so the type might not be at a glance.

s normally give you information like the variable type when typing / hovering over the variable name, but when they don't, or when you are without an IDE, you'd be stuck.

That's why I developed my own notation, which is just expressing your variable names as a complete thought.
In this table, we have a bunch of variable names and how to fix them.

Obvious Nomination

Type	Bad Name	Hint 1	Hint 1 Example	Hint 2	Hint 2 Example	Hint 3	Hint 3 Example
Integer	health	num	numHealth	numberOf	numberOfHealthBars	Can only be a whole number	heartCount
Float	health	amount	healthAmount	amountOf	amountOfHealth	Can only be a float	averageHealth
Bool	dead	is	isDead	Make it a statement	theyAreDead / areDead	Make it a question	areTheyDead / areDead
Pointer	healthBar	pointer	healthBarPointer	pointerTo	pointerToHealthBar	Ptr	healthPtr
Array	healthBar	array	healthBarArray	arrayOf	arrayOfHealthBars	Just make the name plural	healthBars
String	healthStatus	string	healthString	Str	healthStr	Can only be a string	healthMessage

If this seems like it's obvious, that's because it's supposed to be obvious. This makes it so that you don't have to memorize a naming convention from the 1970s-1990s. It compromises knowing the exact type of the variable (doesn't distinguish between float/double or short long numbers) by just telling what the reader needs to know. It makes it easier to remember variable names, and maybe even easier to write them.
Just remember, you only need this when your variable's definition is outside the reader's glance, as "health" is as good a name as any if they can see the type without scrolling.

The main reason for using this convention, is that variables (especially booleans) tend to read very naturally. Ternaries, what used to be scary, becomes a simple question that branches a value.

Typically ternaries are bad because they are a shortcut that people have to learn, but doing this makes

statements intuitive for the reader.
Writing your boolean variables as a question is clean, informative, and fun in a Jeopardy! sort of way. Writing out variables and equations like how natural language works makes reading the code much more intuitive.