TMBTC Post

My Codeing Standards


CODE STANDARDS DEVELOPMENT

My Codeing Standards

2012-11-12

In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types and functions etc. in source code and documentation.

Reasons for using a naming convention

  • to reduce the effort needed to read and understand source code
  • to enhance source code appearance (for example, by disallowing overly long names or abbreviations)

Here are some of the benefits obtained by adopting a common naming convention:

  • to provide additional information (i.e., 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 and to provide better understanding in case of code reuse after a long interval of time

Business value

Although largely hidden from the view of most business users, well-chosen identifiers make it significantly easier for subsequent generations of analysts and developers to understand what the system is doing and how to fix or extend the source code for new business needs.

For example, although the following:
a = b * c;
is syntactically correct, it is entirely opaque as to intent or meaning. Contrast this with:
dblWeeklyPay = dblHoursWorked * dblPayRate;
which implies the intent and meaning of the source code, at least to those familiar with the underlying context of the application.

Comments

Commented code helps future generations of developers easily understand what sections of code are supposed to be doing. Using comment blocks native to the language make note of the major function of the following few lines as well as outline expected input and output (if applicable). Believe it or not commenting your code will help you too.
# qchecker.pl
# This program will check the current Q for any old items
# checkActiveQ
# Function that will look up items in the Active Q
sub checkActiveQ{
  # Code here …
}

Variables

Variables should be prefixed to indicate their data type. Optionally, especially for large programs, the prefix can be extended to indicate the scope of the variable. The body of a variable or procedure name should use mixed case (CamelCase) and should be as long as necessary to describe its purpose. In addition, function names should begin with a verb, such as initNameArray or closeDialog.

For frequently used or long terms, standard abbreviations are recommended to help keep name lengths reasonable. In general, variable names greater than 16 are considered too long.

When using abbreviations, make sure they are consistent throughout the entire application. Randomly switching between cnt and Count within a project will lead to unnecessary confusion.

Variable Data Types

Use the following prefixes to indicate a variable's data type.
Data Type Prefix Example
Boolean bln blnFound
Byte byt bytRasterData
Collection
Object
col colWidgets
Currency cur curRevenue
Date / Time dtm dtmStart
Double dbl dblTolerance
Error err errOrderNum
Integer int intQuantity
Long lng lngDistance
Object obj objCurrent
Single sng sngAverage
String str strFirstName
Variant var varCheckSum

Using CamelCase

Indicate word boundaries using medial capitalization (also called "CamelCase" and many other names), thus rendering "two words" as either "twoWords" or "TwoWords".
  • capitalizationIsUsuallyAtTheBeginning
  • underlines_are_usually_under_the_words_not_the_spaces
  • subject.verb(noun,noun)

Indentation

Indentation rules (most coding standards impose) really contradict
  rules of good writing,
    the way people perceive information,
      and the grammar rules.
Making things (that group naturally, but not syntactically) inside
    parenthesis also contradicts how texts are usually typed.
If (you try to type text that way)
    you'll face misunderstanding even (if programmers read you)
otherwise
    your text will be easy to read,
and your writing will be productive
!


You might also like
simple-bash-script-to-email-server-status

Simple Bash Script To Email Server Status

2012-08-22

I didn't want to constantly have to log into my servers in order to check on key performance indicators so I decided to write a simple script that would do the checking for me. After collecting results, the script emails them to me. There are a few tools called within the script you might need to install. I also convert any tabs into spaces in order to make sure things line up nicely inside my email. #!/bin/bash SERVER="myserver001" TOEMAIL="admin@myservers.com" FROMEMAIL="myserver001@myserverscom" # Who is logged in and what are they up to WHO=`w` #


Read More...

how-to-fix-pagehandlerfactory-integrated-has-a-bad-module-when-setting-up-asp-net

How to fix: “PageHandlerFactory-Integrated” has a bad module when setting up ASP.NET

2012-08-22

I was recently setting up IIS 7.5 on Windows 2008 R2 for an ASP.NET site and came across the following 500 error: Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list. After a bit of searching, it turns out ASP.NET was not completely installed with IIS even though I checked that box in the "Add Feature" dialog. I found a number of suggestions but found this command. It fixed my issues and got rid of the error. %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i For a 32 bit system, use the


Read More...