Coding Best Practices and Solutions

Introduction

Coding or programming is the key activity and an engineering methodology through which the system visualized by the end user in terms of requirements is brought to life. In other words, this can be described as an activity to give a programmatic representation for the architecture and design manifestation of the application that we are trying to build. The major part of the effort spent on any software development project is invariably spent on the construct efforts and hence this activity requires the right attention to ensure the success of the project.

As the industry evolved, with the latest set of tools and technology, the various methodologies and the mature processes that have been practiced by the industry players, the coding activities could be more streamlined and the best results could be aimed to be achieved. Generally the best coding/programming can be achieved by following a set of best practices that include a well defined methodology, a high mature framework which best suits the underlying technology in which the coding is undertaken, the various tools that help the programmer to concentrate on the core of the logic leaving the basic features to the evolved technology and a standardized steps of review, rework and refactoring.

Coding process starts from the early days of solutioning in any project and in many cases, even the proof of concept (POC) code forms the basis or the foundation for the later development. In this whitepaper we would cover the best practices of coding which would be mostly followed in any typical medium scale development project. The major part of the description would be covered under the various categories and the same is as below:

1. Finalization of a methodology
2. Finalization and use of tools for development
3. Tailoring of the process to be used.
4. Coding the application.
5. Check-in Check-out process
6. Automated build process
7. Unit testing and integration testing
8. Review and rework

By following the best practices enlisted below here, we would be able to get the best product out of high quality, within the estimated cost and timelines.

Description

The various steps mentioned above are the key blocks in a process oriented way of development. It is very imperative to have a well defined process to achieve the best outcome of a project as these steps of the process have been evolved from the experience the industry has gained after executing several hundreds of projects.

We would go through each of the steps in detail and see what part they play in the coding phase of the project and what flexibility the development team has in tailoring them to meet their needs.

The following are the very basic steps which are essentially required by a project for the effective usage of Coding Best Practices.

1. Finalization of methodology (Lifecycle)

First and foremost would be to finalize the methodology to be used. It can be either a test driven development, pair programming or an Agile methodology like Extreme Programming. The next step would be to brainstorm and agree on what would constitute the steps of doneness for coding. This should clearly define when a developer can call one’s code as complete. For example, in a typical project coding phase, coding, unit testing, review, rework, integration testing and documentation would be the steps which would be mandatory to call any coding to be complete. This should be agreed on in the early state of the project and every developer should be aware of this.

This step should also identify, at the beginning of the project, what would be an acceptable state of code. The deliverables that would be expected from the developers should be defined.

2. Finalization and use of tools for development process

This is again one of the fundamental steps involved in the software development. This step is considered to be a vital, since, based on this the design and development activities of the project would be commenced. Each decision of the tool and techniques to be used would play a vital role in shaping the application. This step involves the choosing of the following:

a)    Identification of the various infrastructures for the project. This includes identifying the various servers required and the standardization of the software to be used including the OS and the patches that need to be applied. The servers to be used for everyday testing, the SIT and UAT, for example, should be of the same type and should be similar to proposed PROD environment.
b)    Which IDE to be used (Eclipse, JDveloper, and Netbeans etc.)
c)    What other custom tools to be built to take care of everyday operations. For example, it can be a simple activity like setting up user data for navigating across the application. Instead of manually inserting records, such activities should be identified and automated scripts should be written to lessen the burden on the developers
d)    Which build tool to be used.
e)    What repository to be used to take care of the source code
f)    Unit testing tools like HttpUnit or JUnit
g)    Review checklists
h)    Usage of different types of check style.

3. Tailoring of the process to be used

This step is to finalize and agree upon the steps that would be followed during the coding phase. This process is always a case to case basis since the methodology applied by each project would differ in many ways.

Every developer should adhere to the methodology to be followed while developing the application.

a.    Proper requirement walkthrough should be made on which ever the module he/she is going to be worked with. Also it is the responsibility of each developer to ensure that the requirement about the modules they are working on should be clear enough to clarify the issues which shall be raised during the testing phase of the application.
b.    Should agree on what amount of reviews would be done. For example, would only the peer reviews would be done or the reviews would be taken by the leads or both.
c.    Should agree on whether a planned activity for refactoring the code would be added in the plan or there is no scope for it.
d.    Should agree on when the traceability matrix would be updated
e.    Should agree on whether the application delivered by the developer would be validated by a BA before calling it as complete.

Also, it is one of the best coding practices to statically analyze the code by using many of the tools available for the same. This is nothing but the analyzing the developed software which is performed without actually executing the developed one. Sometimes this can be done through by just picking up some version of the source code and sometimes through the usage of object code. There are tools available for this purpose like PMD, JProfiler, OptimizeIT etc.,

It is the sole responsibility of each and every developer to ensure that the code developed by them should meet the client requirements and should result in the minimal or zero defects as well. For e.g. a java developer should be able to code starting from the front end part to the database part which would have minimal transactions without any defects. Ultimately, the source code delivered by each developer should be defect free at the unit testing level.

Once we agree on the set of process, this should be vigorously followed in all the activities that the team undertakes.

4. Coding the application (Development phase)

Coding an application is a vital and a critical as well a small developmental activity in the software development process. The best coding would always result in the best application with minimal/zero defects.  This can be incorporated by adopting the standard coding standards available.

Coding Standard or Programming style can be easily defined as the set of standard rules to be followed in order to deliver a standard code which would result out in a standard application. It includes starting from writing a comment in the code till the deploying the code into a production environment.

Usually, every company derive its own way of programming style/coding conventions, which is again basically built on top of the existing standard coding conventions. Also there are some set of different coding conventions available for different programming languages as well.

The physical appearance of the written source code can be made as an effectively visualized through the implementation of the standard programming styles. A good programming would always result in the development of a fine grained application as well. Any developer irrespective of working on any programming languages should always write the code in such a way, that, any other developer should be able to understand the purpose of the code being written. And also, an important key note is that, any developer should code in keeping the vital concept of maintainability for any sort of future enhancements of the application.

One of the true facts in the field of software engineering is, for most of the developers it consumes lot of time just for coding and testing the application according to the client requirements. It could be due to the very limited deadline, complexity of the application/module a developer working on, not having a clear picture of the requirements etc. In such a confused status, most of the developers would not be able to provide more information about the source code they had written. At this stage of coding, lot of maintainability issues can be found easily.

Hence, the above would create a big mess as and when the application grows bigger every day. In a peak, the developer may find it really difficult to understand the code written by him/her. Therefore, as part of best practices, every developer should always code by following the Standard Coding conventions defined for the programming languages.

The following are the important 9 rules should be followed while writing an object oriented code (according to Object Calisthenics):
1.    Use only one level of indentation per method
2.    Don’t use the else keyword
3.    Wrap all primitives and strings
4.    Use only one dot per line
5.    Don’t abbreviate
6.    Keep all entities small
7.    Don’t use any classes with more than two instance variables
8.    Use first-class collections
9.    Don’t use any getters/setters/properties

Checking in a code without unit testing is unacceptable and a bad practice in the software development process. Every developer should be able to unit test his/her part of the code being written. Code without being unit tested is considered to be a poor practice of programming. This unit testing mechanism helps the developer to ensure the code written is fit for the further high level testing stages like System Integration Testing (SIT) and User Acceptance Testing (UAT).

5. Source code management (Check-in and Check-out process)

Once the code has been written, the same has to be checked in to a repository where a standard project structure would be maintained. So whoever joins the project at the later point of time, can check out the code from the repository and can start working on their respective modules. For this to be achieved standard code check in and checkout process should be followed. The following are some of the tools available to make a code repository:
a)    Sub Version (SVN)
b)    Concurrent Versioning System (CVS)
c)    Visual Source Safe (VSS)
d)    Mercurial
e)    Git

Since it has been become a regular practice in every IT industry that a single document or a source code files to be edited or used by other members of the team. This may due to the people working from different geographical locations.

The main purpose of the this code check in process is to make a centralized repository of the project code in one location and making the source code available to the other developers who may require to work on enhancing the same. In other words this is to maintain a revision control of the developed code. Since many people would be working on the same file while developing an application, there should be a proper version control mechanism to be implemented, so that all changes can be merged and again checked in. So whenever a developer checks out the versioned file will reflect as an updated file and contains all the changes done by different developers.

Basically each revision of the file will be created with a time stamp as well in any of the revision tools used. This will helps the new developer who needs to work on the same file to know when and what changes are being made on the file.

These details are to be ensured before the developer checks out any file from the versioning control system like SVN/VSS/CVS/Git/Mercurial.

6. Automated build and deployment process

Once the code has been unit tested and being checked into the repository, then there should be an automated deployment process made to be carried out in order to deploy the application into different test environments. While developing a large scale application, it is good to have a continuous integration environment where the checked in code can be marked as zero compilation issues. Lot of open source tools are available to achieve this. E.g.  Hudson Build Tool, Cruise Control etc.

Continuous integration is a software development practice where team members will integrate their work on the application frequently. Usually this process will result multiple integrations in one single day. To avoid the basic compilation errors when the integration is being made with the required changes, each integration will be tested with a build just to detect for any sort of compilation issues. By the use of this best practice many people across the industry has made a significant improvement to provide a stable build for testing by avoiding such compilation issues.

One of the major challenging tasks in the software development process is to get a running application with the source code written and make it available for the testing process. In fact many of the tasks in getting an application running can be automated like compilation of the source code, generating war/jar file for the deployment, configuring the database to which the application should be pointing.

Also, another good practice is to have the source code Branched after every significant milestone. Branching of the source code is nothing but making the copy of the code from the main trunk derived from a particular point based on some criteria like achieving a milestone like code completion or start of SIT. This is required in order to preserve the integrity of the source code from the main trunk. All subsequent changes and fixes to this branched code base is made and this code base is stabilized. So once the applied changes work as expected, the same codebase would be merged back into the main trunk.

It is always a good practice that whenever the code is checked out for a new build. It should be tagged with a specific name and other essential details. So that if the current build fails there would be always a chance for the build person to deploy the previously working build. So that the availability of the application access will be ensure all the time. Also the vital reason for preservation of the code using this tag concept is that the particular tagged code is required as part of the major releases like alpha, beta or RTM releases. This tagged code is nothing but a point-in-time code which depicts the current state of the application.

7. Testing the application

Testing is an integral process in the development of an application. One should always ensure that, the testing process of each and every module of the application should be carried away proactively. It is a really good practice to prepare the test cases before the coding phase of the software development process. So that one can ensure that the code which is going to be developed will meet all the client requirements.

The very basic level of testing the application in the software development process is the Unit testing. It is a method by which each individual units of the written source code is being tested and determined whether is the application is fit for the usage. Unit is nothing but the smallest testable portion of an application.

Unit test cases are always case to case. But, it will always be written and executed by the developers for their respective modules to ensure that the code written by them meets the desired design and behaves accordingly.

The primary goal of the unit testing process is to stable each and every part of the application according to the design and requirements. Every unit test provides the developer with a written contract that every piece of source code should satisfy.

Unit testing can be achieved by using tools like JUnit or HTTPUnit. JUnit is one of the very frequently used as unit testing frameworks/tool.

So, once the unit testing process is successfully carried out by the developer, then the same code has to be checked in to the repository and check out the source code into a new project and then the application has to be tested rigorously. This is a regression testing process in order to ensure that the checked in code should not break the other existing modules.

Apart from the adopting of basic level of testing like unit testing, it is also a very good practice to do a code coverage analysis. It is a structural testing technique which compares the test program behavior and apparent intention of the source code. Basically it is a process of:
a)    Finding areas of a program not exercised by a set of test cases,
b)    Creating additional test cases to increase coverage, and
c)    Determining a quantitative measure of code coverage, which is an indirect measure of quality.
The basic idea of doing this technique is to assure the quality of the set of test cases and not to determine the quality of the product. Code Coverage analysis requires access to test program source code and often requires recompiling it with a special command.

8. Review and Rework

Once the deployment is successfully on the destination server, it is the Duty of the developer to ensure his/her module is behaving according to the design and development of the application. There would be many review process involved in the application as well. It could be with the basic step of the code review, where the source code will be reviewed for the coding conventions and other basic coding practices are being implemented or not.

Always proper rework should be made on the review comments provided after reviewing the source code and module as well. Also it has to be ensured that there should be only minimal no. of rework which incorporates major changes.

QA team would test the application for regression issues and will check whether the functionality of the application is intact. Whenever there is an issue in the application, a defect would be raised for the same and would ask the concerned developer to look into that issue. Once the developer comes to know about the issue in his/her respective module is required to start working on to fix the issue based on the review comments given by the QA team.

Summary

Following the best coding practice will always result in a better application. The above are the vital coding best practices being followed across many IT industries in order to deliver a stable application with a better performance. To summarize, the following are the key advantages of adopting the best coding practices in any software development life cycle process:

1.    A high quality output can be obtained with minimal rework within the planned efforts, cost and time.
2.    A very scalable application can be built and delivered which can form the basis for the future changes in the application.
3.    The further phases in the project like SIT / UAT would be going as planned as majority of issues would be found in the unit testing phase.
4.    Also the code delivered will be meeting the expectations of the customers.
5.    As the quality of the application is of a high standard, would reduce rework efforts.
6.    This always reduces the duplication of the efforts.
7.    Improved risk management.
8.    It eliminates the wasteful investment of time and resources.
9.    Also, it would really result in a high morale of the team.

Disclaimer:- This article is written by Keerthi Kumar N and first published at codeproject.com