Ten Coding Pillers

Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices and methods for each aspect of a piece program written in this language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers. As a result, not following some or all of the rules has no impact on the executable programs created from the source code.

 
But in the blog I would like to put 10 best  coding pillars / rules for best coding practices above any particular technology / platform .

First and the foremost rule is that your code should only implement what’s required, no more no less. Primary focus of your implementation should be to cover the requirements, and tasks like creating reusable components, additional features like offline mode support etc should be included only if additional time and resources are available. As an extension to this rule, you should also make sure that only the required libraries, frameworks and resources are included in your project, this will reduce the overall size of your app binary and will avoid confusion.

Second, your code should implement the required task in the simplest way possible. If you find something that is getting complex, take sometime to simplify it. It is always faster and cheaper to replace complex code earlier, before you waste a lot more time on it. A simple design always takes less time to finish than a complex one, so always do the simplest thing that could possibly work. Consider an example: you multiply by 100 to turn a fraction into percentage and you also multiply by 100 to turn meters into centimeters. Should you have a single function that multiplies by 100 calledconvertToPercentOrMeters(x)? NO! Not even if it would remove some duplication. You want two methods; converToPercent(aFraction), andconvertMetersToCentimeters(aLength). You want two because they tell you different things. Not just that you will multiply by 100 but also why you will multiply by 100 and what kinds of numbers are valid inputs.

Third, your code should meet the basic performance requirements interns to time and memory efficiency of the applied algorithm, so that the user experience is not compromised. Algorithms must be analyzed to determine their resource usage. For maximum efficiency we wish to minimize resource usage. However, the various resources i.e. time, space cannot be compared directly, so which of two algorithms is to be more efficient often depends on which measure of efficiency is being considered as the most important, e.g, is the requirement for high speed, or for minimum memory usage, or for some other measure?

Fourth, your code should have proper error handling, it should be able to recover from the error without blocking users and should produce comprehensive error messages. Error handling refers to the anticipation, detection and resolution of application errors. Syntax errors are easy to find and fix, with the help of compliers. Logic errors, also called bugs, occur when executed code does not produce the expected result. These are best handling with the help of debugging tools, this can be an ongoing process that involves, in addition to the traditional debugging routine, beta testing prior to official release and customer feedback after official release.

Fifth, your code and design should avoid repetition at all levels possible, this include right from declaring variable with similar purpose, writing comments, writing functions, declaring classes to designing high level modules. In software engineering we have a principle, don’t repeat yourself (DRY), its aimed at reducing repetition of information of all kinds. It states as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Violation of DRY are typically referred to as WET solutions, which is commonly taken to stand for either “write everything twice” or “we enjoy typing”.

Sixth, your code should have comments which are accurate, clear, concise and only at the required places. To know where to add comments in code is always a subjective matter, one way to get around with this is by adding comments on all the places in code where you would have given an explanation while explaining your code to some other developer, probably a developer with lesser experience and expertise. Always remember that code tells you how, comment tell you why.

Seventh, your code should adhere to coding standards. Coding standards specify a common format for the source code and comments. This allows developers to share code, and the ideas expressed within the code and comments, between each other. If also specifies how comments (internal documentation) should be handled. More importantly, a well designed standard will also detail how certain code should be written, not just how it looks on screen.

Eighth, your code should have symbolic constants for hard-coded values. Its not always possible to completely eliminate hard-coded values from the code, but you can always replace them with more meaningful symbolic constants this will make your code more readable. A benefit of symbolic constants over variables is they are evaluated by the PRE-processor, i.e. they are re-written as literal values, not as variables. Thus run-time access to symbolic constants is significantly faster than access to variables.

Ninth, your code should use data structures and algorithms available in the language or its libraries. As software industry is getting matured, languages and libraries in all areas are getting equipped with rich set of data structures and algorithms. If you dig deep enough, you’ll find the required data structures and algorithms for the task in your native language or its libraries. Few advantages of using native data structures and algorithms are, the lesser code you write the lesser code you have to test and maintain, language and its libraries are throughly tested and stable, results in avoiding third party libraries thus reducing the overall resources in the app and they are commonly share and understood by the developers hence easy to communicate.

 Tenth, last but not the least your code should be thoroughly tested. The importance of testing and its impact on software cannot be underestimated. Software testing is a fundamental component of software quality assurance and represents a review of specification, design and coding. Testing can provide objective, independent information about the quality of software and risk of its failure to developers.

A software is a large complex system which is built as a combination of intermediate stable forms of small simple units, we can define these units in as smaller form as functions or as larger as software modules. Hence these points must be applied from the smallest units of a software like functions to the larger units like software modules, because the only way to maintain an overall quality of your software is by maintaining it right from it’s smallest unit to the software as a whole.

Hopefully the information shared in this blog was useful, and perhaps you have been inspired to implement these in your code more rigorously. Please share your views and feedback in the comments – we would like to hear from you.