Coding Standards
A Presentation by Jordan Belone
What are They?
• Rules - Must
• Guidelines - Should
• Physical Document
Open Source
• GNU
http://www.gnu.org/prep/standards/standards.html
• Firefox
https://developer.mozilla.org/En/Developer_Guide/Cod
ng_Style
Prominent Works
-Kernighan and Plauger (1974)
-Fortran and PL/I
- Contains important points
Prominent Works (2)
-Rob Pike
-More recent (Published in
1999)
- Regarded as “a business
essential” and has been
proven to save money
-C/C++/Java
Kernighan Quotations
• "Where there are two bugs, there is likely to
be a third.“
• “Don't patch bad code - rewrite it."
• "Don't stop with your first draft."
Why Have Coding Standards?
• Software Maintenance
• Less Bugs
• Teamwork
• Team switching
• Cost
TYPES OF CONDING STANDARDS
• BY COMPANY
• BY LANGUAGE
Common Practice - Indentation
• Identifies scope in some programming languages
for the compiler
• Indentation of
– Functions
– Objects
– Etc
• Unnecessary in Freeform programming <Java>
• Gives an indication of scope in freeform languages
but doesn’t affect program
Example
Compare
if (g < 17 && h < 22 || i < 60) { return true; } else {System.out.println (“incorrect”) ; return
false; }
To
if (g < 17 && h < 22 || i < 60)
{ - Easier to Read
return true;
} - Easier to Understand
else
{ - Easier to maintain
System.out.println(“incorrect”);
return false;
}
Common Practice -Commenting Code
• ALL PROGRAMMING LANGUAGES
• Comments should
- Clearly demonstrate the function of the code,
both to yourself and to other developers
- Not too long
• Comments should NOT be
- Every line (Exceptions for functional languages)
- Overcomplicated
Common Practice - Whitespace
• Very important but often overlooked
• Makes the code easier to read
• Especially important with large programs, lack
of whitespace can be very confusing
Example
for(int i=0;i<40;i++)
{system.out.println(i);}
for( int i = 0 ; i < 40 ; i++ )
{
system.out.println(i);
}
Common Practice – Naming Variables
• Variable names are often thought to be less
important but they are vital to understanding
certain pieces of code.
• In the majority of programming languages,
variables can be assigned almost any name.
Example
If(a < h && z <o && t<e)
{
return true; This code could
} do anything!
else
{
return false;
}
Example quotations from different
coding standards
• Use spaces not TABs.
• Three character indent (four is more common; get agreement and enforce with a tool).
• No long lines. Limit the line length to a maximum of 120 characters.
• No trailing whitespace on any line.
• Put brace on a new line.
• Single space around keywords, e.g. if (.
• Single space around binary operators, e.g. 42 + 69
• No space around unary operators, e.g. ++i
• No space before parentheses with functions/macros, e.g. fred( 42, 69 )
• Single space after parentheses with functions/macros, e.g. fred( 42, 69 )
• Single space after comma with functions/macros, e.g. fred( 42, 69 )
• Layout lists with one item per line; this makes it easier to see changes in version control.
• One declaration per line.
• Function calls with more than two arguments should have the arguments aligned vertically.
• Avoid big functions and methods. Ditto for large classes and large files.
• Avoid deep nesting.
• Always use braces with if statements, while loops, etc. This makes changes shorter and clearer in
version control.
SUMMARY
• EASE OF INFORMATION EXTRACTION
• LOOKING FORWARD
