Top 5 Coding Rules You Must Keep In Mind

In this article I talk about the fundamentals of the software construction. They are the things that everyone must know, because they are as fundamental as the “Hello world!” program.

1. Minimizing Complexity

Every programmer must realise that after code is created it is used by many other people: by testers, engineers or even by the same programmers in the future. That is why code must be easy to understand. Most people have difficulties when they operate with complicated structures. Hence, the simplicity of code is more important than many other factors. The code also should be simple and readable.

There are some techniques to achieve these code qualities.

  1. Use of standards;
  2. Modular design;
  3. Meaningful naming and code layout;
  4. Use of classes, enumerated types, variables and named constants;
  5. Code documentation and comments.

To speak more specifically from a practical point of view you can use the following approaches while coding:

  1. Divide the system in subsystems in order to concentrate on a smaller part of the system time at any given time;
  2. Use the abstraction by thoroughly defined classes and structures. That allows not to keep in mind too much information;
  3. Avoid global data, because they are always have to be kept in mind. This is a useless way to spend your energy and concentration;
  4. Avoid too deep inheritance, conditional and loop hierarchies;
  5. Do not use goto operator. It makes the program non-linear and as a result difficult to understand;
  6. Define and use the same approach to handle errors;
  7. Do not create bulky classes and methods;
  8. Minimize the number of input parameters for methods (according to statistics, their number should not exceed seven).

The most powerful way to minimize complexity is abstraction of all types. That is why the transition from low-level programming languages to high-level ones is one of biggest achievement in the history of programming.

IMPORTANT: You create code for people, but not for computers! Make It Simple!

2. Anticipating change

Anticipating change helps engineers build extensible software, which means that they can enhance a software product without causing violence to the underlying structure.

Software is unavoidably part of changing external environments, and changes in those outside environments affect software in diverse ways.

One of the rules you can follow to simplify the future correction of the program is using variables and named constants instead of literals. To change one value is much easier than 10 values. Moreover, the probability of a mistake is also much less.

3. Constructing for Verification

Constructing for verification means building software in such a way that faults can be weeded out easily by the software engineers writing the software as well as testers and users during independent testing and operational activities. Specific techniques that support constructing for verification include following coding standards to support code reviews, unit testing, organizing code to support automated testing, and restricting the use of complex or hard-to-understand language structures, among others.

4. Reuse

In most engineering disciplines, systems are designed by composing existing components that have been used in other systems. Previously, software construction was primarily focused on original development, but now it is recognized that systematic software reuse allows to achieve better results, more quickly and at lower cost.

Reuse refers to using an asset in solving different problems. In software construction, typical assets that are reused include:

  • Application systems: The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families. COTS stands for commercial off-the-shelf. That is an item that is commercially available, leased, licensed, or sold to the general public and which requires no special modification or maintenance over its life cycle.
  • Components (subsystems, modules, libraries)
  • Objects and functions

Reuse should be practiced systematically, according to a well-defined, repeatable process. Systematic reuse can enable significant software productivity, quality, and cost improvements.

Reuse also brings the following benefits:

  • Increased dependability of the system. Reused software has already been tested and fixed. Hence, it requires less time for these activities than new software;
  • Reduced process risk. It’s much simpler for process management to assess the costs of reusing software than costs of development;
  • Effective use of specialists. Programmers do not spend their time on developing software already created. Also work becomes more creative and less routine, when a programmer creates reusable software;
  • Accelerated development. Reusing software drastically speeds up software production. It allows to bring a system to market earlier.

Reuse has two closely related facets: “construction for reuse” and “construction with reuse.” The former means to create reusable software assets, while the latter means to reuse software assets in the construction of a new solution. Reuse often transcends the boundary of projects, which means reused assets can be constructed in other projects or organizations.

5. Standards

Applying external or internal development standards during construction helps achieve the project’s objectives for development efficiency, quality, and cost. Specifically, the choices of allowable programming language subsets and usage standards are important aids in achieving higher security. Standards that directly affect construction issues include:

  • Communication methods (for example, standards for document formats and contents)
  • Programming languages (for example, language standards for languages like Java and C++)
  • Platforms (for example, programmer interface standards for operating system calls)
  • Tools (for example, diagrammatic standards for notations like UML (Unified Modeling Language))

Use of external standards. Construction depends on the use of external standards for construction languages, construction tools, and technical interfaces. Standards come from numerous sources, including hardware and software interface specifications (such as the Object Management Group (OMG)) and international organizations (such as the IEEE or ISO).

Use of internal standards. Standards may also be created on an organizational basis at the corporate level or for use on specific projects. These standards support coordination of group activities, minimizing complexity, anticipating change, and constructing for verification. The example of internal standards:

  • Conventions for variables naming, comment and code format;
  • Specific description of the integration procedure;
  • Have programmers to create tests before construction?;
  • Have programmers to perform mutual reviews and code inspection?;
  • Instrument, which is used for versions management;
  • Programming language, the version of the programming language and the version of the compiler;
  • Code editor, testing platform; and
  • Other.

This article is based on three sources: the SWEBOK guide, Software Engineering by Ian Sommerville, and Code Complete by Steve McConnell.

Thank you for reading!