let name = "Jon Snow"; // binding that starts with a letter followed by a digit const castle1 = "Winterfell"; // binding that starts with _ followed by a digit const _1stOne = "firstOne"; // binding that starts with $ followed by a digit const $2nd = "second";
So the only constraint is that a name can’t start with a digit, you will get an error if you try to do this:
// This doesn't work const 1st = "first"; const 2nd = "second";
By convention, the name of all members, bindings, functions starts in lower case. Class names start with upper case.
camelCaseNotation is used for names composed from several words of all other names:
const nameOfTheGame = "football"; const isDone = false; const numberOfBottles = 3;
const name = "Jon"; const Name = "Snow"; const NAME = "JON";
A special case is program level constants are entirely upper case and we separate words with underscores:
const DATABASE_IP = '22.214.171.124'; const LEVEL_WARNING = "LEVEL_WARNING";
For example, if you make a Chess program, the number of squares on the board is 64 so you can use a program level constant, BOARD_SQUARES for that. All Sudoku boards have 81 squares, so that’s a program-level constant.
// This doesn't work const const = "const"; let let = "let";
Here is the list of reserved words that you cannot use to name your stuff:
Good programmers understand that they spend most of the time reading code, not writing new code. We write a piece of code once, but we read it many times: to fix bugs, to refactor it, to extend it, to reuse it, to use it as a base for new code.
Imagine that you come back to it after several weeks or months. If the code is not clear you will have a hard time understanding how the code is working. If you work in a team, that piece of code you wrote a while back will be read by several people, maybe somebody else will have to use your code and they’ll have to understand it. Will they be able to understand it? Will you be able to understand it after a while?
One of the things that make the code clear or not is the naming of the abstractions from that code. Everything, from the name of a binding to the name of a function or a class counts.
Naming things is hard but important. Please spend time to find eloquent names for things. Future you will thank you.
- Don’t use one letter names
- Don’t use
bar, or other meaningless names
- Don’t use magic numbers, make them program level constants, attach a name to a number. For example, don’t use
- Don’t use confusing or unexpected names, use the right name for the context. For example, don’t use an
- Don’t name different things with the same name. For example, don’t use
Headerfor the site header and an article header, use
- Don’t use general, ambiguous names like Manager, Service, Controller, Handler, Factory, Object, Interface, etc.
- Don’t exagerate with long names. For example, don’t use
In practice this is hard to do, is fast and a no-brainer to use a bad name. Think a bit about it. Ask yourself if is the right one.
- There are rules to name things.
- Keywords are words with a meaning
- Naming things is hard, so spend some time finding the most appropriate ones
Time is up. Looks like we didn’t get to data types, so let’s do that next time.