8 Best Rules for Good Programming Style

Proper programming style significantly reduces maintenance
costs and increases the lifetime and functionality of software. Most software
disasters are rooted in poor style of programming. In this article I am listing
out the 8 best rules that lead to a better programming style.
8 Best Rules for Good Programming Style

Readability

Good code is written to be easily understood by colleagues.
It is properly and consistently formatted and uses clear, meaningful names for
functions and variables. Concise and accurate comments describe a natural
decomposition of the software’s functionality into simple and specific
functions. Any tricky sections are clearly noted. It should be easy to see why
the program will work and reason that it should work in all conceivable cases.

Maintainability

Code should be written so that it is straightforward for
another programmer to fix bugs or make changes to its functionality later.
Function should be general and assume as little as possible about preconditions.
All important values should be marked as constants which can be easily changed.
Code should be robust to handle any possible input and produce a reasonable
result without crashing. Clear messages should be output for input which is not
allowed.

Comments

Comments are the first step towards making computer program
human readable. Comments should explain clearly everything about a program
which is not obvious to a peer programmer. The volume of comments written is
meaningless, quality is all that counts.
Block comments are written using /* comments */ style. They should go at the top of every source
file and generally include your name, the date your code was written and
overall description of the purpose of that program. Block comments should also
precede most functions with a description of the function’s purpose; these can
be omitted for very short, obvious functions only.
Inline comments are written as //comments, they should go near important lines of code within
functions or with variables when they are initialized.

Naming

Names given to classes, variables, and functions should be
unambiguous and descriptive. Other guidelines for naming are:
  • Capitalization is used to separate multi-word names:
    StoneMasonKarel.
  • The first letter of a class name is always capitalized:
    GraphicsProgram
  • The first letter of a function or variable name is always in
    lowercase: setFilled().
  • The names x and y should only be used to describe
    coordinates.
  • The names i, j, and k should only be used as variables in
    for loops.
  • Other one-letter names should be avoided: area = base *
    height instead of a = b * h.
  • Names of constants are capitalized, with underscores to
    separate words: BRICK_COLOR.
  • Use abbreviations with caution. max instead of maximum is
    fine, but xprd instead of crossProduct is a problem.

Indentation

Indentation is used to clearly mark control flow in a
program. Within any bracketed block, all code is indented in one tab. This
includes the class body itself. Each additional for, while, if, or switch
structure introduces a new block which is indented, even if brackets are
omitted for one line statements. For if statements, any corresponding else
statements should line up

White Space

White space is meaningless to compilers, but should be used
consistently to improve readability. Typically three blank lines are left in
between functions. Individual blank lines are used within functions to separate
key sections. Use of spaces varies as well, but inserting one space usually
make expression more readable; next = 7 *
(prev – 1)
is clear than next=7*(prev-1).

Function Usage

Function should be short and accomplish a clear, specific
task. As much as possible they should be considered “black boxes” which do not
depend on anything except their parameters and can be handle any possible input
gracefully. A common rule of thumb is the “Ten Line Rule”, usually function
longer than ten lines are trying to do too much and should be simplified.
Another important aspect of functions is that any repeated
segments of code should be made into a separate function. This will shorten
your program and improve readability.

Output

A final, overlooked aspect of good programming style is how
our program output results and information to users. Part of writing
professional looking programs is providing clear instructions and results to
the users of our programs. This means proper English with no spelling error conditions.
One must always assume that writing programs to be used by somebody with no
understanding of computer programming whatsoever.
If you liked the article then please share it!

3 thoughts on “8 Best Rules for Good Programming Style”

Leave a Comment

Your email address will not be published. Required fields are marked *