CSC/ECE 517 Fall 2010/ch5 5b mt: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(48 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<p style="font-size: 24px">'''Variable Naming Conventions'''</p>
<p style="font-size: 24px">'''Variable Naming Conventions'''</p>
 
It has been written, "[p]rograms must be written for people to read, and only incidentally for machines to execute."<sup><span id="1body">[[#1foot|[1]]]</span></sup> Variables, which hold the data for the program, are used in all computer programming languages and are used for various reasons; such as, holding the value of a constant, holding the value of something used many times throughout the program, or even used briefly for counting.  The names used for each variable are more difficult to choose than simply making any letter or word combination.  The rest of this article is dedicated to helping the novice programmer choose good variable names.
As a popular saying goes, source code is meant to be read by humans; it is only a coincidence that it is also interpreted by machines.  Holding the data for source code, variables are used in all computer programming languages and are used for various reasons; such as, holding the value of a constant, holding the value of something used many times throughout the program, or used briefly for counting.  The names used for each variable are more difficult to choose than simply making any word or word combination.  The rest of this article is dedicated to helping the novice programmer choose good variable names and convention-styles for when writing their code.




==Introduction==
==Introduction==
A [http://en.wikipedia.org/wiki/Variable_%28programming%29 Variable] is a name used within a program that holds the value of something that is known or unknown.  For example, the variable "firstName" might be used to hold the string of letters that comprises a person's first name.  The variable may not be set at the beginning of the program and it may change multiple times after being set.  [http://en.wikipedia.org/wiki/Naming_convention_%28programming%29 Naming conventions] are a set of rules used to guide the programmer when creating the names of variables.  Using the previous example, if there were no naming conventions, the variable could be named "fn", which is ambiguous and would be hard to follow when reading through many lines of code.  Therefore, general naming conventions, which are incorporated by many languages are needed to aid the ability to follow the code without having the author present.  General naming conventions are not perfect; thus, many coding languages have adopted their own type of convention.  Furthermore, there are universally used variables and special types of variables that are used without regard for a language type.
A [http://en.wikipedia.org/wiki/Variable_%28programming%29 Variable]<sup><span id="2body">[[#2foot|[2]]]</span></sup> is a name used within a program that holds the value of something that is known or unknown.  For example, the variable "firstName" might be used to hold the string of letters that comprises a person's first name.  The variable may or may not be set at the beginning of the program and it may change multiple times after being set.  [http://en.wikipedia.org/wiki/Naming_convention_%28programming%29 Naming conventions] <sup><span id="3body">[[#3foot|[3]]]</span></sup> are a set of rules used to guide the programmer when creating the names of variables.  Thinking about a variable to hold first names again, if there were no naming conventions, then the variable could be named "fn".  Context could allow a reader to understand the purpose variables, and in a user information form the variable "fn" could be understood to hold the person's first name.  However, if the variable is used later in a [http://en.wikipedia.org/wiki/Concatenation concatenation], which is a joining of separate variables or [http://en.wikipedia.org/wiki/Ascii ascii] characters, it may be harder to follow what is being used.  For example, after the user finishes filling out the account creation form the program creates a temporary password in a separate method.  The code for this password is:
<pre> tp = "1892" + fn + un + dc + td; </pre> 
In the password example above, can you figure out what each of the variables holds?  Maybe or maybe not, but so can check yourself: the variable tp is the temporary password, fn is the user's first name, un is the username, dc is the date created, and td is today's date. This simple example should help you see the importance of using good variable names.  Therefore, general naming conventions, which are incorporated by many languages, are used by a programmer to create a program that is easier to read ad understand its purpose.  General naming conventions are not perfect; thus, many coding languages have adopted their own type of convention [[#Additional Resources | Additional Resources]].


==Popular Naming Conventions==


||An example of multiple cites for the same resource <sup><span id="1bodya">[[#1foot|[1]]]</span></sup> <sup><span id="1bodyb">[[#1foot|[1]]]</span></sup> If it doesn't have multiple cites for the same resource just leave off the ''a'' and ''b''
To help establish consistency, a few variable naming conventions were created to give programmers a method for writing variable names. There are two main ways of thinking about naming variables - style and content.  Style refers to what the variable looks like and content refers to the substance of the name. There are a few conventions that deal with the style of variables, which include single word names; white space, hyphens and underscores separating words and camel case. There are only two main conventions used that affect the content of the variable, and they are Hungarian notation and common sense.


||
===Single Words===
Often times a variable represents a very simple idea like name, location, address, or license.  For simple programs, these single word variables work very well.  However, more times than not, a program wants to split the information and put it in a database in a logical manner, like first name, last name, GPS coordinates, street address, driver license number, driver license state.  So, if multiple words are needed to define the variables, other style mechanisms are needed.


==The Good and The Bad==
===White space===
A white space is generally considered a delimiter for token parsing; thus it is not recommended for use in variable names.  Furthermore, many language conventions do not allow white space because one can call or create many variables on one line with just a white space between them - <code>int left motor right motor</code>.  In that example, some languages would create four variables, when the intention was to have just two variables, <code>left motor</code> and <code>right motor</code>.  Therefore, one has to establish a non-white space system for a variable that has more than one word in it.  For example, if one wants to reference a "First Name" data string, there are many different ways we could establish a variable name for this (e.g. fName, first_Name, FirstName, etc...).


Imagine you are diving into someone's code, and you find something like this...
===Hyphens and Underscores===
[http://en.wikipedia.org/wiki/Hyphen#Hyphens_in_computing Hyphens] '-' have been around since the beginning of programming with COBOL and LISP (i.e. END-OF-FILE). However, since some programming languages can subtract one string from another the hyphen was replaced by the underscore '_'.  Underscores provide a good amount of near whitespace; thereby, making the separated words stand out easier.  For example, <code>date_of_birth</code> is easier to read than <code>dateofbirth</code>.  Underscores are also used as special variable identifiers when placed at the beginning of the variable (VB, C++, C#). Unfortunately, the technological advance from punch cards to dot-matrix printers and regular character set to ASCII has, at times, made the underscore unreadable, misaligned or sometimes merged with underlined text. Therefore, the next movement of variable styling went to camel case, even though hyphens and underscores are currently used in many programming languages.


  1  '''function''' mystery_function(''var1'', ''var2''):
===Camel Case===
  2      '''for each''' vertex ''v'' in ''var1'':
[http://en.wikipedia.org/wiki/CamelCase Camel Case] is a generic name for a naming style in which the variables have capital letters at the beginning of some or all of the words. The two most common forms of camel case are lower and upper camel case. Lower camel case format starts the variable name off with a valid, lowercase letter, and then the first letter of each new word is capitalized. This allows each word to be easily distinguished without injecting any unnatural characters into the variable name. For our "First Name" example, we would reference this as <code>firstName</code>. Upper camel case is the same as lower except that the first word is capitalized. Again, using the "First Name" example, the variable would read <code>FirstName</code>.
  3          var3[''v''] := infinity ;
  4          var4[''v''] := undefined ;
  5      '''end for ''';
  6      var3[''var2''] := 0 ;
  7      ''var5'' := the set of all nodes in ''var1'' ;
  8      '''while''' ''var5'' '''is not''' empty:
  9          ''var7'' := vertex in ''var5'' with smallest var3[] ;
  10          '''if''' var3[''var7''] = infinity:
  11              '''break''' ;
12          '''fi''' ;
13          remove ''var7'' from ''var5'' ;
  14          '''for each''' neighbor ''var6'' of ''var7'':
  15              ''var8'' := var3[''var7''] + dist_between(''var7'', ''var6'') ;
16              '''if''' ''var8'' < var3[''var6'']:
  17                  var3[''var6''] := ''var8'' ;
  18                  var4[''var6''] := ''var7'' ;
19              '''fi ''' ;
20          '''end for''' ;
21      '''end while''' ;
22      '''return''' var3[] ;
23  '''end''' mystery_function.


Clearly, code without meaningful variables greatly complicates reading what the algorithm is supposed to do.  Even with a slightly better example, using really short variable names, can be difficult to understand.
===Hungarian Notation===
[http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation] is a naming convention that was intended to be used in any language and is used to impact the content of the variable. There are two types of this notation, Systems and Apps.  Hungarian Systems notation requires the variable to be prefixed by the data type of the variable's use.  For example, a float number that is used to hold the value of the circumference of a circle would be defined as <code>fCircleCircumference</code>.  


  1  '''function''' mystery_function(''G'', ''s''):
Hungarian Apps notation requires the purpose of the variable it's prefix. For example, the Apps variable name for a circle's circumference would be <code >numCircleCircumference</code>.
  2      '''for each''' vertex ''v'' in ''G'':
  3          d[''v''] := infinity ;
  4          p[''v''] := undefined ;
  5      '''end for ''';
  6      d[''s''] := 0 ;
  7      ''Q'' := the set of all nodes in ''G'' ;
  8      '''while''' ''Q'' '''is not''' empty:
  9          ''u'' := vertex in ''Q'' with smallest d[] ;
  10          '''if''' d[''u''] = infinity:
11              '''break''' ;
12          '''fi''' ;
13          remove ''u'' from ''Q'' ;
14          '''for each''' neighbor ''v'' of ''u'':
15              ''a'' := d[''u''] + dist_between(''u'', ''v'') ;
16              '''if''' ''a'' < d[''v'']:
17                  d[''v''] := ''a'' ;
18                  p[''v''] := ''u'' ;
19              '''fi ''' ;
20          '''end for''' ;
21      '''end while''' ;
22      '''return''' d[] ;
23  '''end''' mystery_function.


Finally, here is the same algorithm, with the original variable names from the [http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm#Pseudocode source-example] (include reference number here).
The two types of Hungarian notation are similar, but the easiest way to remember the them is through their difference.  Systems notation looks at the specific type for the variable: l for long, f for float, d for double; whereas, Apps just uses the generic name: num for any number or str for a string.  


  1  '''function''' mystery_function(''Graph'', ''source''):
In reference to our "First Name" example, we know that this variable will hold a string. A candidate Hungarian Apps notation variable name could be <code>strFirstName</code>.
  2      '''for each''' vertex ''v'' in ''Graph'':
  3          dist[''v''] := infinity ;
  4          previous[''v''] := undefined ;
  5      '''end for ''';
  6      dist[''source''] := 0 ;
  7      ''Q'' := the set of all nodes in ''Graph'' ;
  8      '''while''' ''Q'' '''is not''' empty:
  9          ''u'' := vertex in ''Q'' with smallest dist[] ;
  10          '''if''' dist[''u''] = infinity:
11              '''break''' ;
12          '''fi''' ;
13          remove ''u'' from ''Q'' ;
14          '''for each''' neighbor ''v'' of ''u'':
15              ''alt'' := dist[''u''] + dist_between(''u'', ''v'') ;
16              '''if''' ''alt'' < dist[''v'']:
17                  dist[''v''] := ''alt'' ;
18                  previous[''v''] := ''u'' ;
19              '''fi ''' ;
20          '''end for''' ;
21      '''end while''' ;
22      '''return''' dist[] ;
23  '''end''' mystery_function.


So finally, with meaningful variable names in place, it is much easier to understand the purpose of the code.  In fact, many may recognize it as Dijkstra's algorithm.  Comparing this well-named example to our first example shows just how important naming can be when writing code.
===Common Sense===
 
When writing code in a program, whether established or just at the beginning, [http://en.wikipedia.org/wiki/Common_sense common sense] should be used when creating variables. This means using full words or appropriate, commonly used abbreviations in the variable name.  For example, a variable that holds the street address should be <code>streetAddress</code> and not <code>strAddress</code> because strAddress could be street address or string address in the case of Hungarian Apps notation.  For more information on using common sense when naming variables see the [[#Naming_Variables | Naming Variables]] section.
<hr >
 
==Popular Naming Conventions==
===Hungarian===
[http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation] is a naming convention that was intended to be used in any language. There are two types of this notation, Systems and Apps.  Systems notation requires the variable to be prefixed by the data type of the variable's use.  For example, a float number that is used to hold the value of the circumference of a sprocket would be defined as <span style="color:darkblue">fSprocketCircumference</span>. Apps notation requires the purpose of the variable it's prefix.  Using the previous example, the Apps definition would be <span style="color:darkblue">numSprocketCircumference</span>.


===Universally Used Variables===
===Universally Used Variables===
Line 107: Line 43:
* dir - holds the string of a folder in a file system
* dir - holds the string of a folder in a file system
* e - holds the value of the system error
* e - holds the value of the system error
* foo, bar, foobar - variables used in examples showing how to use new code in many languages


== Naming Variables==
As a previously written wiki article states "[c]hoosing a good variable name means naming a variable in a way that will help the reader understand the program's design and purpose"<span id="4body"><sup>[[#4foot|[4]]]</sup></span>.  You should have many goals when writing a program, the top two are below.
# Does this program do what I need it to do?
# After I no longer need to own the code, will other people be able to read my code and understand how it works.


===Special Variable Conventions===
The first goal is the most important because if the program does not do what it is advertised for, then no one will want to use it.  Let's say that the code works exactly the way you want, and you posted it to the internet for all to use for free.  As it will undoubtedly turn out, the code will most likely not be perfect and will require modifications to fit the needs of other people.  If they look at your code and cannot figure out how the stuff that goes into the program comes out the way it does, they will be unhappy and your new support email box will be full.  To circumvent some of the questions that may come your way, you can make your program more readable.  The first step is to create variables with names that make sense.  To help you out, there are a few things that you should and should not do as well as some key questions you should ask yourself when creating those variable names.


<hr/>
=== Do's And Don'ts ===


== Dos And Don'ts ==
When picking your variable names, here are a few '''Do's''' and '''Don'ts''' to consider. <span id="5body"><sup>[[#5foot|[5]]]</sup></span>
 
When picking your variable names, here are a few '''Do''' and '''Don'ts''' to consider.


* Do use meaningful words
* Do use meaningful words
* Do use intention-revealing names (p 84 java book)
* Do use intention-revealing names
* Do be descriptive
* Do be descriptive
* Do keep consistent in your naming convention
* Do keep consistent in your naming convention


* Don't ever name your variables, "data" ( http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html )
* Don't ever name your variables, "data" <sup><span id="6body">[[#6foot|[6]]]</span></sup>


* Don't use needless variables, eg.
* Don't use needless variables, e.g.
** <code>FOURTY_TWO = 42;</code>
** <code>FORTY_TWO = 42;</code>
** <code>x = 4; one_more_than_x = x + 1</code>
** <code>x = 4; one_more_than_x = x + 1</code>


* Don't give up!
* Don't give up!


== Questions to Ask ==
=== Questions to Ask ===
There are some questions that you should ask yourself before you decide on a naming scheme for your variables.  These questions when answered should give the programmer the needed answers for the naming scheme.<span id="7body"><sup>[[#7foot|[7]]]</sup></span>


* Will my variable names by understood?
* Will my variable names by understood?
Line 136: Line 76:
* Will they be easy to get right as more code is written?
* Will they be easy to get right as more code is written?
* Will they get confused with one another?
* Will they get confused with one another?
* Will they fall in line with the language's naming conventions?
==Code Readability Example==
Armed with these given tools, an example that demonstrates good and bad variable naming conventions is given.  Which example is good and which one is bad?
The purpose of the given code is to read in an online food order and give some information back to the customer.
<table width="900px">
<th> Example 1</th>
<th> Example 2</th>
<tr>
<td width="450">
numberHamburgers - 1; <br/>
numberCheeseBurgers - 1; <br/>
numTacquitos - 9; <br/>
sizeFries[] - [3, 2, 3]; <br/>
typeAndSizeDrink[] = [(Coke,3), (DrPepper,2)]; <br/>
<br/>
subTotalSandwiches = numberHamburgers *priceHamburgers + numberCheeseBurgers*priceCheeseBurgers + numberTacquitos*priceTacquitos; <br/>
.<br/>
.<br/>
.<br/>
subTotal = subTotalSandwiches + subTotalFries + subTotalDrink; <br/>
tax = subTotal * 0.625; <br/>
total = subTotal + tax; <br/><br/>
output("Your total is " + total); <br/>
output("Have a great day!); <br/>
</td>


(Source http://www.wellho.net/solutions/general-what-makes-a-good-variable-name.html )
<td width:"450px">
numHams - 1;<br/>
numCB - 1;<br/>
numT - 9;<br/>
F[] - [3, 2, 3];<br/>
d[] = [(Ck,3), (dPr,2)];<br/><br/>
 
Ss = numHams*pHams + numCB*pCB + numT*pT;<br/>
.<br/>
.<br/>
.<br/>
S = Ss+Sf+Sd;<br/>
T = S*0.625;<br/>
t = S + T;<br/><br/>
out("Your total is " + t);<br/>
out("Have a grate day!);<br/>
</td>
</tr>
</table>
 
Example 1 is clearly the most readable and easiest to understand code to follow.  The variables all have the same coding style and content.  However, notice that Example 2 uses the same coding style throughout the variable definitions.  It is compact and everything fits on one line.  So, even with the same coding style used throughout the code, the name itself needs to be understandable for the overall code to be understandable.


==Conclusions==
==Conclusions==
Line 143: Line 132:


==References==
==References==
<span id="1foot">1. <sup>[[#1bodya|''a'']], [[#1bodyb|''b'']]</sup></span> Author last, FI. (2010, April 26). Title of webpage. Retrieved October 15, 2010, from site name (Github): http://github.com/
<span id="1foot">[[#1body|''1.'']]</span> Abelson, H., Sussman, G.J. (1996). Structure and Interpretation of Computer Programs - 2nd Ed. Cambridge: The MIT Press.
 
<span id="2foot">[[#2body|''2.'']]</span> Wikipedia. 21 October 2010. Variable (programming). Retrieved November 03, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Variable_%28programming%29
 
<span id="3foot">[[#3body|''3.'']]</span> Wikipedia. 03 November 2010. Naming convention (programming). Retrieved November 03, 2010, from Wikipedia:http://en.wikipedia.org/wiki/Naming_convention_%28programming%29
 
<span id="4foot">[[#4body|''4.'']]</span> Wikipedia. 07 July 2008. Variable Naming in Programming. Retrieved November 22, 2010, http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_2_rapodraz
 
<span id="5foot">[[#5body|''5.'']]</span> Skrien, D. (2009). Object-Oriented Design Using Java. New York: McGraw-Hill.
 
<span id="6foot">[[#6body|''6.'']]</span> Lester, A. 06 March 2004. The world's two worst variable names.  Retrieved November 03, 2010, from O'REILLY: http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html
 
<span id="7foot">[[#7body|''7.'']]</span> Well House Consultants LTD. (n.d.). What makes a good variable name?. Retrieved November 03, 2010, from http://www.wellho.net/solutions/general-what-makes-a-good-variable-name.html


==Additional Resources==
==Additional Resources==
* Ruby naming conventions - http://rubylearning.com/satishtalim/ruby_names.html
* Sun Java naming conventions - http://www.oracle.com/technetwork/java/codeconventions-135099.html#367
* Sun Java naming conventions - http://www.oracle.com/technetwork/java/codeconventions-135099.html#367
* .NET 4 naming conventions - http://msdn.microsoft.com/en-us/library/ms229045.aspx
* .NET 4 naming conventions - http://msdn.microsoft.com/en-us/library/ms229045.aspx
* C++ naming conventions - http://www.cprogramming.com/tutorial/style_naming_conventions.html
* C++ naming conventions - http://www.cprogramming.com/tutorial/style_naming_conventions.html
* Hungarian Notation - http://en.wikipedia.org/wiki/Hungarian_notation
* Hungarian Notation - http://en.wikipedia.org/wiki/Hungarian_notation
** Hungarian notation was invented by Microsoft programmer Charles Simonyi.
** While Hungarian notation can be applied to any programming language and environment, it was widely adopted by Microsoft for use with the C language, in particular for Microsoft Windows

Latest revision as of 20:16, 23 November 2010

Variable Naming Conventions

It has been written, "[p]rograms must be written for people to read, and only incidentally for machines to execute."[1] Variables, which hold the data for the program, are used in all computer programming languages and are used for various reasons; such as, holding the value of a constant, holding the value of something used many times throughout the program, or even used briefly for counting. The names used for each variable are more difficult to choose than simply making any letter or word combination. The rest of this article is dedicated to helping the novice programmer choose good variable names.


Introduction

A Variable[2] is a name used within a program that holds the value of something that is known or unknown. For example, the variable "firstName" might be used to hold the string of letters that comprises a person's first name. The variable may or may not be set at the beginning of the program and it may change multiple times after being set. Naming conventions [3] are a set of rules used to guide the programmer when creating the names of variables. Thinking about a variable to hold first names again, if there were no naming conventions, then the variable could be named "fn". Context could allow a reader to understand the purpose variables, and in a user information form the variable "fn" could be understood to hold the person's first name. However, if the variable is used later in a concatenation, which is a joining of separate variables or ascii characters, it may be harder to follow what is being used. For example, after the user finishes filling out the account creation form the program creates a temporary password in a separate method. The code for this password is: 

 tp = "1892" + fn + un + dc + td;

In the password example above, can you figure out what each of the variables holds? Maybe or maybe not, but so can check yourself: the variable tp is the temporary password, fn is the user's first name, un is the username, dc is the date created, and td is today's date. This simple example should help you see the importance of using good variable names. Therefore, general naming conventions, which are incorporated by many languages, are used by a programmer to create a program that is easier to read ad understand its purpose. General naming conventions are not perfect; thus, many coding languages have adopted their own type of convention Additional Resources.

Popular Naming Conventions

To help establish consistency, a few variable naming conventions were created to give programmers a method for writing variable names. There are two main ways of thinking about naming variables - style and content. Style refers to what the variable looks like and content refers to the substance of the name. There are a few conventions that deal with the style of variables, which include single word names; white space, hyphens and underscores separating words and camel case. There are only two main conventions used that affect the content of the variable, and they are Hungarian notation and common sense.

Single Words

Often times a variable represents a very simple idea like name, location, address, or license. For simple programs, these single word variables work very well. However, more times than not, a program wants to split the information and put it in a database in a logical manner, like first name, last name, GPS coordinates, street address, driver license number, driver license state. So, if multiple words are needed to define the variables, other style mechanisms are needed.

White space

A white space is generally considered a delimiter for token parsing; thus it is not recommended for use in variable names. Furthermore, many language conventions do not allow white space because one can call or create many variables on one line with just a white space between them - int left motor right motor. In that example, some languages would create four variables, when the intention was to have just two variables, left motor and right motor. Therefore, one has to establish a non-white space system for a variable that has more than one word in it. For example, if one wants to reference a "First Name" data string, there are many different ways we could establish a variable name for this (e.g. fName, first_Name, FirstName, etc...).

Hyphens and Underscores

Hyphens '-' have been around since the beginning of programming with COBOL and LISP (i.e. END-OF-FILE). However, since some programming languages can subtract one string from another the hyphen was replaced by the underscore '_'. Underscores provide a good amount of near whitespace; thereby, making the separated words stand out easier. For example, date_of_birth is easier to read than dateofbirth. Underscores are also used as special variable identifiers when placed at the beginning of the variable (VB, C++, C#). Unfortunately, the technological advance from punch cards to dot-matrix printers and regular character set to ASCII has, at times, made the underscore unreadable, misaligned or sometimes merged with underlined text. Therefore, the next movement of variable styling went to camel case, even though hyphens and underscores are currently used in many programming languages.

Camel Case

Camel Case is a generic name for a naming style in which the variables have capital letters at the beginning of some or all of the words. The two most common forms of camel case are lower and upper camel case. Lower camel case format starts the variable name off with a valid, lowercase letter, and then the first letter of each new word is capitalized. This allows each word to be easily distinguished without injecting any unnatural characters into the variable name. For our "First Name" example, we would reference this as firstName. Upper camel case is the same as lower except that the first word is capitalized. Again, using the "First Name" example, the variable would read FirstName.

Hungarian Notation

Hungarian notation is a naming convention that was intended to be used in any language and is used to impact the content of the variable. There are two types of this notation, Systems and Apps. Hungarian Systems notation requires the variable to be prefixed by the data type of the variable's use. For example, a float number that is used to hold the value of the circumference of a circle would be defined as fCircleCircumference.

Hungarian Apps notation requires the purpose of the variable it's prefix. For example, the Apps variable name for a circle's circumference would be numCircleCircumference.

The two types of Hungarian notation are similar, but the easiest way to remember the them is through their difference. Systems notation looks at the specific type for the variable: l for long, f for float, d for double; whereas, Apps just uses the generic name: num for any number or str for a string.

In reference to our "First Name" example, we know that this variable will hold a string. A candidate Hungarian Apps notation variable name could be strFirstName.

Common Sense

When writing code in a program, whether established or just at the beginning, common sense should be used when creating variables. This means using full words or appropriate, commonly used abbreviations in the variable name. For example, a variable that holds the street address should be streetAddress and not strAddress because strAddress could be street address or string address in the case of Hungarian Apps notation. For more information on using common sense when naming variables see the Naming Variables section.

Universally Used Variables

There are commonly used variables that programmers use no matter what language he/she is coding in. The following list does not constitute acceptance of the variables as properly named. The most common are:

  • i, j, k - used for counting especially in short code snippets
  • x, y, z - used for holding the position of an object
  • file - to indicate a placeholder for the location of a file
  • dir - holds the string of a folder in a file system
  • e - holds the value of the system error
  • foo, bar, foobar - variables used in examples showing how to use new code in many languages

Naming Variables

As a previously written wiki article states "[c]hoosing a good variable name means naming a variable in a way that will help the reader understand the program's design and purpose"[4]. You should have many goals when writing a program, the top two are below.

  1. Does this program do what I need it to do?
  2. After I no longer need to own the code, will other people be able to read my code and understand how it works.

The first goal is the most important because if the program does not do what it is advertised for, then no one will want to use it. Let's say that the code works exactly the way you want, and you posted it to the internet for all to use for free. As it will undoubtedly turn out, the code will most likely not be perfect and will require modifications to fit the needs of other people. If they look at your code and cannot figure out how the stuff that goes into the program comes out the way it does, they will be unhappy and your new support email box will be full. To circumvent some of the questions that may come your way, you can make your program more readable. The first step is to create variables with names that make sense. To help you out, there are a few things that you should and should not do as well as some key questions you should ask yourself when creating those variable names.

Do's And Don'ts

When picking your variable names, here are a few Do's and Don'ts to consider. [5]

  • Do use meaningful words
  • Do use intention-revealing names
  • Do be descriptive
  • Do keep consistent in your naming convention
  • Don't ever name your variables, "data" [6]
  • Don't use needless variables, e.g.
    • FORTY_TWO = 42;
    • x = 4; one_more_than_x = x + 1
  • Don't give up!

Questions to Ask

There are some questions that you should ask yourself before you decide on a naming scheme for your variables. These questions when answered should give the programmer the needed answers for the naming scheme.[7]

  • Will my variable names by understood?
  • Will they provide information to the maintenance programmer?
  • Will they be easy to get right as more code is written?
  • Will they get confused with one another?
  • Will they fall in line with the language's naming conventions?

Code Readability Example

Armed with these given tools, an example that demonstrates good and bad variable naming conventions is given. Which example is good and which one is bad?

The purpose of the given code is to read in an online food order and give some information back to the customer.

Example 1 Example 2

numberHamburgers - 1;
numberCheeseBurgers - 1;
numTacquitos - 9;
sizeFries[] - [3, 2, 3];
typeAndSizeDrink[] = [(Coke,3), (DrPepper,2)];

subTotalSandwiches = numberHamburgers *priceHamburgers + numberCheeseBurgers*priceCheeseBurgers + numberTacquitos*priceTacquitos;
.
.
.
subTotal = subTotalSandwiches + subTotalFries + subTotalDrink;
tax = subTotal * 0.625;
total = subTotal + tax;

output("Your total is " + total);
output("Have a great day!);

numHams - 1;
numCB - 1;
numT - 9;
F[] - [3, 2, 3];
d[] = [(Ck,3), (dPr,2)];

Ss = numHams*pHams + numCB*pCB + numT*pT;
.
.
.
S = Ss+Sf+Sd;
T = S*0.625;
t = S + T;

out("Your total is " + t);
out("Have a grate day!);

Example 1 is clearly the most readable and easiest to understand code to follow. The variables all have the same coding style and content. However, notice that Example 2 uses the same coding style throughout the variable definitions. It is compact and everything fits on one line. So, even with the same coding style used throughout the code, the name itself needs to be understandable for the overall code to be understandable.

Conclusions

Variables are inevitable in programming. The naming of variables must be taken with caution so that they make sense to any who read through the code. When creating names of variables the author should take into account the language of the code, the purpose of the variable, and the type of value the variable will hold. Adhering to naming conventions is not a requirement, but they are merely guides that a programmer can use to determine the best way to name the program's variables.

References

1. Abelson, H., Sussman, G.J. (1996). Structure and Interpretation of Computer Programs - 2nd Ed. Cambridge: The MIT Press.

2. Wikipedia. 21 October 2010. Variable (programming). Retrieved November 03, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Variable_%28programming%29

3. Wikipedia. 03 November 2010. Naming convention (programming). Retrieved November 03, 2010, from Wikipedia:http://en.wikipedia.org/wiki/Naming_convention_%28programming%29

4. Wikipedia. 07 July 2008. Variable Naming in Programming. Retrieved November 22, 2010, http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_2_rapodraz

5. Skrien, D. (2009). Object-Oriented Design Using Java. New York: McGraw-Hill.

6. Lester, A. 06 March 2004. The world's two worst variable names. Retrieved November 03, 2010, from O'REILLY: http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html

7. Well House Consultants LTD. (n.d.). What makes a good variable name?. Retrieved November 03, 2010, from http://www.wellho.net/solutions/general-what-makes-a-good-variable-name.html

Additional Resources

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch5_5b_mt&oldid=42468"