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

From Expertiza_Wiki
Jump to navigation Jump to search
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.


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...
* If your language changes, i.e. is updated, code may need to be changed so the naming convention still fits.


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.
* 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.
 
So, do the disadvantages outweigh the advantages?  No... I would still use naming conventions for the simple fact of readability.  As 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.


=== Common conventions ===
=== Common conventions ===

Revision as of 01:33, 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

  • 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.
  • 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.
  • Contants should have every letter capitalized, with underscores between words.

References

External Links

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki2_2_ao&oldid=13993"