QA Friday 2015-Dec-04

Take Up Code - En podcast af Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Kategorier:

In the last live weekend programming class, I created a variable called scrambledWord and then later created a method called scrambleWord. The method was a good name. It started with a verb and described exactly what it did. And the name of the variable was good too. It described a word that had been scrambled. But there was confusion when the variable and the method were used together. The reason is because it’s very easy to miss the single extra letter d in scrambledWord. This episode gives you some guidance for avoiding names that are too similar. Listen to the full episode or read the full transcript below. Transcript Okay on to the question this week. In the last live weekend programming class, I created a variable called scrambledWord and then later created a method called scrambleWord. The method was a good name. It started with a verb and described exactly what it did. And the name of the variable was good too. It described a word that had been scrambled. Putting the variable and the method together caused confusion. The reason is because it’s very easy to miss the single extra letter d in scrambledWord. The implied question is what do you do in this situation? Is this okay? I changed the variable name in the 5-day email course to be called wordAfterScramble instead because you don’t really want to have names that are so similar. I normally try to avoid naming variables similar names. This slipped past me as I was conducting the class because one was a variable and the other name was for a method. And it still caused confusion. I suggest that you avoid naming variables anything that is just a single character different than another name. And especially avoid names that differ only in upper vs. lower case. There are some exceptions to this rule and here are three that I can think of right now.  Sometimes, I’ll create several variables and number them. This usually happens in my test cases. I always try to avoid numbered variables in the product code. Some variables are just a single letter long. If you have some of these, then at least avoid characters that look the same from a distance. So don’t name one with an l and another with an i. And really, the need for single letter variable names is more of a convention than a need. Many loops will use a variable named i to keep track of how many times the loop has run. i stands for index. There’s nothing wrong with calling your loop variable index and it avoids a single letter name. lhs and rhs are two very common names used in method parameters for operators. An operator method is one that defines behavior for symbols such as the + or the * and allow you to write custom types that resemble the natural behavior of builtin types such as an int. When writing your own operators, it’s very common to refer to the left hand side as lhs and the right hand side as rhs. I should also mention now even though we haven’t talked about it yet about method overloading. This is a concept in many object-oriented languages that allows you to write multiple methods that each have the same name but with different type and numbers of parameters. This is okay and is not what I’m talking about when I recommend that you avoid naming variables and methods with slightly different names. Overloaded methods will have exactly the same name and there’s a good reason for this. We’ll discuss overloaded methods and also operator methods too in a future episode once we get to object-oriented programming.

Visit the podcast's native language site