CSC/ECE 517 Summer 2008/wiki2 2 ao: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by the same user not shown)
Line 13: Line 13:


=== Naming conventions disadvantages ===
=== Naming conventions disadvantages ===
* First, what happens when you change a variable type? You have to go change ALL the instances of that variable within your code. Some editors have some pretty sophisticated find-and-replace tools, so this wouldn't be that big of an issue... but it still needs to be done.
* When a variable type is changed, you may have to go through and change ''all'' the instances of that variable within your code. The find-and-replace feature of many editors alleviates this issue a bit, but it may still be tedious.
* If your language changes, i.e. is updated, code may need to be changed so the naming convention still fits.
* Naming conventions may defeat the purpose of encapsulation.  The "black box" aspect is eliminated when the programmer needs to know what specific type is being returned.


Second, what happens if you upgrade your language, and what was a 16-bit integer is now a 32-bit integer? Now you have to go change portions of your code so your naming convention still fits...
=== Common conventions ===
* Packages should have prefixes always written in all-lowercase ASCII letters and they should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.  Examples: <tt>com.sun.eng</tt>, <tt>com.apple.quicktime.v2</tt>, and <tt>edu.cmu.cs.bovik.cheese</tt>.
* Class names should be nouns, in mixed case with the first letter of each word capitalized.  They should be simple and descriptive, and whole words should be used (avoid acronyms and abbreviations).  Examples: <tt>class Roster;</tt>, <tt>class ImageSprite;</tt>.
* Interface names should be capitalized like class names.  Examples: <tt>interface RosterDelegate;</tt>, <tt>interface Storing;</tt>.
* Lowercase letters should be used for variable and method names.  A name consisting of several words should be concatenated into one word (take out the spaces).  The first word should be all lowercase, and each subsequent word (the internal words) should have its first letter capitalized.  Methods should be verbs.  Examples: <tt>run();</tt>, <tt>runFast();</tt>, and <tt>getBackground();</tt>
* Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.  Variable names should not start with underscore ("<tt>_</tt>") or dollar sign ("<tt>$</tt>") characters, even though both are allowed.  Examples: <tt>int i;</tt>, <tt>char c;</tt>, and <tt>float myWidth;</tt>.
* The names of variables declared ''class constants'' and of ''ANSI constants'' should be all uppercase with words separated by underscores ("<tt>_</tt>"). Examples: <tt>static final int MIN_WIDTH = 4;</tt>, <tt>static final int MAX_WIDTH = 999;</tt>, and <tt>static final int GET_THE_CPU = 1;</tt>.
 
=== Hungarian notation ===
 
One of the most popular naming conventions is Hungarian notation, which encodes either the purpose ("Apps Hungarian") or the type ("Systems Hungarian") of a variable in its name. Some examples of "Apps Hungarian" are:
* <tt>rwPosition</tt>: variable represents a row ("rw")
* <tt>usName</tt>: variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used
* <tt>strName</tt>: Variable represents a string ("str") containing the name, but does not specify how that string is implemented


Third, naming conventions can defeat the purpose of encapsulation. Encapsulation means "black box" right? So why does the programmer need to know what specific type is being returned? They just create a variable of that class, and then use it. Who cares if it’s a long, or a string, or an object.
Some examples of "Apps Hungarian" are as follows:
* <tt>lAccountNum</tt>: variable is a long integer ("l")
* <tt>arru8NumberList</tt>: variable is an array of unsigned 8-bit integers ("arru8")
* <tt>szName</tt>: variable is a zero-terminated string ("sz")


So, do the disadvantages outweigh the advantages?  No... I would still use naming conventions for the simple fact of readabilityAs I stated before, using naming conventions in your programming allows you to read your variable types (and their purpose) at a glance... No need to go looking for a declaration.
=== Final conclusions ===
The advantages of using naming conventions outweigh the disadvantagesReadability is the biggest derived benefit, and its importance cannot be overstated.  Variable types, as well as their purpose (for classes and modules too) can be determined at a quick glance. Readers unfamiliar with the code can derive meaning and purpose quicker, without having to study large portions of the code and refer to various places within. The following tips should be used when choosing names for variables, classes, modules, etc.:


=== Common conventions ===
* Prefix the variable names with their scope and their data types
* Lowercase letters should be used for variable and method names.  A name consisting of several words should be concatenated into one word (take out the spaces).  The first word should be all lowercase, and each subsequent word should have its first letter capitalized.
* Use meaningful variable names  
* Class names should have the first letter of each word capitalized.  Multi-worded names should follow the rule above, except that the first word should also be capitalized.
* Be wary of long names  
* Contants should have every letter capitalized, with underscores between words.
* Use your conventions consistently


=== ''References'' ===
=== ''References'' ===

Latest revision as of 02:52, 26 June 2008

Variable, Class, and Module Naming

When programming, choosing appropriate names for variables, classes, modules, etc. can often be taken too lightly. It's always important to choose descriptive names with straightforward meanings. Certain conventions should be followed to ensure code can be read, followed, and edited easily.

Naming conventions advantages

  • to provide additional information (ie, metadata) about the use to which an identifier is put
  • to help formalize expectations and promote consistency within a development team
  • to enable the use of automated refactoring or search and replace tools with minimal potential for error
  • to enhance clarity in cases of potential ambiguity
  • to enhance the aesthetic and professional appearance of work product (for example, by disallowing overly long names, comical or "cute" names, or abbreviations)
  • to help avoid "naming collisions" that might occur when the work product of different organizations is combined
  • to provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation

Naming conventions disadvantages

  • When a variable type is changed, you may have to go through and change all the instances of that variable within your code. The find-and-replace feature of many editors alleviates this issue a bit, but it may still be tedious.
  • If your language changes, i.e. is updated, code may need to be changed so the naming convention still fits.
  • Naming conventions may defeat the purpose of encapsulation. The "black box" aspect is eliminated when the programmer needs to know what specific type is being returned.

Common conventions

  • Packages should have prefixes always written in all-lowercase ASCII letters and they should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981. Examples: com.sun.eng, com.apple.quicktime.v2, and edu.cmu.cs.bovik.cheese.
  • Class names should be nouns, in mixed case with the first letter of each word capitalized. They should be simple and descriptive, and whole words should be used (avoid acronyms and abbreviations). Examples: class Roster;, class ImageSprite;.
  • Interface names should be capitalized like class names. Examples: interface RosterDelegate;, interface Storing;.
  • Lowercase letters should be used for variable and method names. A name consisting of several words should be concatenated into one word (take out the spaces). The first word should be all lowercase, and each subsequent word (the internal words) should have its first letter capitalized. Methods should be verbs. Examples: run();, runFast();, and getBackground();
  • Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters. Variable names should not start with underscore ("_") or dollar sign ("$") characters, even though both are allowed. Examples: int i;, char c;, and float myWidth;.
  • The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). Examples: static final int MIN_WIDTH = 4;, static final int MAX_WIDTH = 999;, and static final int GET_THE_CPU = 1;.

Hungarian notation

One of the most popular naming conventions is Hungarian notation, which encodes either the purpose ("Apps Hungarian") or the type ("Systems Hungarian") of a variable in its name. Some examples of "Apps Hungarian" are:

  • rwPosition: variable represents a row ("rw")
  • usName: variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used
  • strName: Variable represents a string ("str") containing the name, but does not specify how that string is implemented

Some examples of "Apps Hungarian" are as follows:

  • lAccountNum: variable is a long integer ("l")
  • arru8NumberList: variable is an array of unsigned 8-bit integers ("arru8")
  • szName: variable is a zero-terminated string ("sz")

Final conclusions

The advantages of using naming conventions outweigh the disadvantages. Readability is the biggest derived benefit, and its importance cannot be overstated. Variable types, as well as their purpose (for classes and modules too) can be determined at a quick glance. Readers unfamiliar with the code can derive meaning and purpose quicker, without having to study large portions of the code and refer to various places within. The following tips should be used when choosing names for variables, classes, modules, etc.:

  • Prefix the variable names with their scope and their data types
  • Use meaningful variable names
  • Be wary of long names
  • Use your conventions consistently

References

External Links