- We are going to start a series of videos
that discuss the topic of good programming practices.
The first one is about "Defining and using
"meaningful naming conventions."
Let's see what we mean by that.
Naming conventions refer to names, labels
you choose for functions and variable in your code.
There could be good and bad notations.
However, this is subjective.
It is very hard to say that something
or some notation, convention is
universally good or universally bad.
Most likely, it is an evolution
based on different criteria, personal preferences,
regulations, style of management,
requirements for documentation, experience
of the programmers, and so on.
All we can do at this point is to give you some tools
that will help you assess on your own
whether a particular naming convention that you chose,
if it's a convention at all, is appropriate
or that requires some improvement.
First of all, does it make sense to you?
When you look at a variable name,
x or height or max price,
does that name resonates with you?
Do you feel like when you look at the code,
yeah, it's obvious that somebody
would use this name for the variable.
When you show this code to someone else,
does it make sense to them?
Will they look at it and be completely clueless
about what the program does in spite of the fact
that they are very experienced programmers?
Does it help making the code more readable?
If you had to debate between labeling something x
or labeling something x one
or a or a very long name,
when you made the decision, did you ask yourself
whether this decision makes the code more readable?
Ultimately, the code is not just about running,
well, saving time, being resourceful.
If the code is not very readable,
it might be difficult for somebody to improve it.
Which means longer revision cycles.
The company might actually lose money because it cannot
improve its own code for lack of readability.
Whatever you think you are saving,
because you made your code more efficient,
you may lose in the long term
because nobody can improve it.
Finally, if you look at your naming conventions,
is there any aspect of your naming choices
that made the code better in any way?
Whether it's readability and maintenance,
makes sense to you, makes sense to other,
whatever is there that you can point to.
Let's see what this means in the code.
This is not entirely a running code
but it's mostly an illustration because it helps
seeing these things in the context of a program
rather than outside in a PowerPoint.
I listed here a comparison between what
I personally considered good and bad choices.
You might have another opinion.
The most important thing that you are able
to critically think evaluate your requirements
and criteria and make the best decision
out of all the options that are available to you.
Let's look at line 17.
RoomNumbers, it's the name for an array.
It's very descriptive I supposed to rm
which would be short for rooms,
after the fact if somebody explained to me.
In this case, I choose roomNumbers.
Line 18, firstNumInSeries
versus firstnuminseries.
I know it says firstNumInSeries in both places
but did you when you first looked at it?
The main difference obviously is
the camelback notation on the good column
which definitely makes those words stand out.
Line 19, I have a double twiceTheRisk.
It's unrelated to anything.
On the right, double doubler.
So I tried to show a common core in terms
of the meaning, one starts with the word
twice, the other with the one double.
I made this confusing to illustrate that
you really don't want to name a variable
the same word almost that you used for a type.
So double doubler, great opportunity for confusion.
Line 20 through 22, there are conventions
for writing about milesPerGallon.
Typically, if you would go to a car dealership
and they will show you the car facts
or any other sticker information, you will see
the notation MPG, lowercase or uppercase.
Rarely you would see one word called milesPerGallon
even though it makes more sense
with the camelback notation and so on.
I really do not have an alternative
to the MPG on the bad side but I do have
a bad alternative to milesPerGallon.
Obviously, It's the one without the camel notation.
Finally, line 24, five, and six,
I initialize three variables, x, y, and z, to zero
versus putting them all in one line.
It's really hard to say whether one
is better than the other.
It's a matter of style.
That's why I said even though I think
it's a bad habit, it is often acceptable.
If we continue to look at some rules that I put here.
Again, nothing runs.
It's not meant to run in this code but I wanted
to put those recommendation in the context of code.
So rule of thumb, ask yourself
whether the name of a variable, a function,
a macro makes sense to you.
When you look at your code, try to extrapolate
and put yourself into the future.
Maybe a week from now and say,
are you going to remember next week or next month
or in a year what you meant when you said x equals 12?
If your project needs to be transferred to somewhere else
so you can get the promotion, will they be able
to understand your code or perhaps you will
stay stuck in your lower level position
because you are the prisoner of your code?
There are multiple reason why you want your code
not only to be fast, elegant, well-documented,
good naming convention, good structure.
You never know when somebody will come to you
and say, "You did such a great job.
"I want you to now become the manager of their team."
And you don't want to tell them,
"Look, I would love to but frankly if I leave,
"nobody else will be able to deal with this code."
Or the manager might tell you this,
"I would really love to promote you
"but unfortunately, your code is such a genius.
"Only you can handle it."
So word of caution and be careful
and trust your senses, trust your common sense.
In time, those thing would become second nature to you.