Information Technology Reference
In-Depth Information
customer's suppliers, contractors, customers, and so on. So the application should
be easily integratable with these myriad systems. Requirements keep changing very
often; this is a fact of life. The design should be flexible enough to take care of these
changes in requirements.
1..
Definition of Good Code
Good code is code that works as intended, is reasonably defect-free, and is readable
and maintainable. Most organizations have coding standards that all developers
adhere to. Over time, organizations develop a framework that becomes mature
and reliable. There are too many methodologies out there, but organizations
should stick to what suits them best for their projects. Also excessive use of stan-
dards and rules stifle the productivity and creativity of team members. So some
room for creativity should be left. In fact software development is such a creative
endeavor that no project team can develop any software application just by adher-
ing to processes.
Peer reviews, pair programming, code analysis tools, and so on, can be used to
check for problems and enforce standards. For object-oriented programming, here
are some typical ideas to consider in setting rules/standards:
Use descriptive function and method names—use both uppercase and low-
Minimize or eliminate use of global variables.
ercase, avoid abbreviations, and use as many characters as necessary to be
adequately descriptive. Be consistent in naming conventions.
Use descriptive variable names—use both uppercase and lowercase, avoid
abbreviations, and use as many characters as necessary to be adequately
descriptive. Be consistent in naming conventions.
Function and method sizes should be minimized. Less than 100 lines of code
is good; less than 50 lines is preferable.
Function descriptions should be clearly spelled out in comments preceding a
function's code.
Organize code for readability.
Each line of code should contain 70 characters max.
Use white spaces generously—vertically and horizontally.
Coding style should be consistent throughout a program (e.g., use of brack-
One code statement per line.
ets, indentations, naming conventions).
In adding comments, err on the side of too many rather than too few com-
ments; a common rule of thumb is that there should be at least as many lines
of comments (including header blocks) as lines of code.
Search WWH ::




Custom Search