Best Coding Practices

Best coding practices for software development can be broken into many levels based on the coding language, the platform, the target environment and so forth. Using best practices for a given situation greatly reduces the probability of introducing errors into your applications, regardless of which software development model is being used to create that application.

There are standards that originated from the intensive study of industry experts who analyzed how bugs were generated when code was written and correlated these bugs to specific coding practices. They took these correlations between bugs and coding practices and came up with a set of rules that when used prevented coding errors from occurring. These standard practices offer incredible value to software development organizations because they are pre-packaged automated error prevention practices; they close the feedback loop between a bug and what must be done to prevent that bug from recurring.

In a team environment or group collaboration, best coding practices ensure the use of standards and uniform coding, reducing oversight errors and the time spent in code review. When work is outsourced to a third-party contractor, having a set of these best practices in place gives you the knowledge that the code produced by the contractor meets all the guidelines mandated by the client company.

It should be understood that these practices are not just a way to enforce naming conventions in your code.

Best coding practices gives you a way to analyze your source code so that certain rules and patterns can be detected automatically and that the knowledge obtained through previous years of experience by industry experts is implemented in an appropriate way.

With the foregoing in mind, here is a some base step of what is needed for a project that successfully utilizes 'Best Coding Practices':

Commenting

Due to the time restrictions or enthusiastic programmers who want immediate results for their code, Commenting of code took a back seat until recently, the programmers working as a team found it to be better to leave comments behind since coding usually follows cycles, or more than one person may work on a particular module. Hence, It was made a "good practice" to leave comments behind in code.

One commenting practice is to leave a brief description of the following:

1. Name of the module. 2. Purpose of the Module. 3. Description of the Module (In brief). 4. Original Author 5. Modifications 6. Authors who modified code with a description on why it was modified.

Also regarding complicated logic being used, it is a good practice to leave a comment "block" so that another programmer can understand what exactly is happening.

Well written code can be self-explanatory, so heavily commented code can indicate poor code quality. Unit testing can be better than commenting to show how code is intended to be used. Modifications and authorship can be reliably tracked using a source-code revision control system, rather than using comments. Commments can add a development and maintenance overhead.

Goal of the Code

(Why was the code written and what purpose does it serve ?)

Another good practice is to know the goal of the code. Never begin coding without understanding why the code is being written and what is it being written for.

Questions to ask yourself while coding:

1. Is this a small function which will never be replaced ? 2. Will there be any modifications to this function ?

Mostly, there are functions that fetch dates from the system and display it to the users on their web pages, such functions usually don't need replacement or modifications.

However in complex projects, there are a lot of things that may need alteration or addition or even removal. Therefore always document the code as it is being modified so that the goal of the code is clear at all the steps.

Debugging the code and correcting errors

Programmers usually tend to write the complete code and then begin debugging and checking for errors. Though this approach can save time in smaller projects, bigger and complex ones tend to have too many variables and functions that need attention. Therefore, it is good to debug every module once you are done and not the entire program. This saves time in the long run so that one does not end up wasting a lot of time on figuring out what is wrong.

Naming conventions

Use of proper naming conventions are considered good practice. Sometimes programmers tend to use X1, Y1, etc as variables and forget to replace them with meaningful ones, causing confusion.

In order to prevent this waste of time, it is usually considered good practice to use descriptive names in the code since we deal with real data.

Example: A variable for taking in weight as a parameter for a truck can be named TrkWeight or TruckWeight with TruckWeight being the more preferrable one since it is instantly recognisable. See [[camelcase]Camel Case] naming of variables.

Keep the code simple

The Code that a programmer writes should be simple and complicated logic for achieving a simple thing can be kept to the minimum since the code might be modified by another programmer and the logic one programmer implemented may not make perfect sense to another. So, always keep the code as simple as possible.

Guidelines in brief

A general gist of all of the above:

1.Know what the code block must perform 2.Indicate a brief description of what a variable is for (reference to commenting) 3. Correct errors as they occur. 4.Keep your code simple 5.Maintain naming conventions which are uniform throughout.

Lifecycle

It is important to choose the appropriate development lifecycle for a given project because all other activities are derived from this process. A couple of examples of this are the Rational Unified Process (RUP) and the eXtreme Programming (XP) methods. Having a well-defined process is usually better than having none at all, and in many cases it is less important what process is used than how well it is executed. The methodologies above are very common and a quick Web search will turn up all kinds of information regarding how to implement them.

Requirements

Main article: Requirements engineering

Everyone needs to be on the same page before jumping into programming. This is a fundamental truth to almost any endeavor and even more so when accomplishing a group driven programming task. If you are programming alone, you may find yourself adding or tweaking your application. When you are looking at an enterprise piece of software, everyone involved in the project needs to understand clearly the requirements and goals of the project before moving forward. This is often referred to as Functional and Detailed Specifications.

Architecture

Main article: Software architecture

Choosing the appropriate architecture for your application is key. You have to know what you are building on before you can start a project. Check the architecture of the target. Read as much as you can about the ins and outs of the platform and note any pitfalls before you start your code. It will go a long way to heading off any bugs that might be 'show stoppers' later on.

Design

Main article: Software design

Even if you feel great about knowing the architecture of your target platform without a good design you are going to be sunk. Try not to fall into the trap though of over-designing the application. The two basic principles are to "Keep it Simple" and to utilize information hiding (Don't show the user more than they need to see). Often this is where object-oriented analysis and UML come in. Do an internet search on UML and you'll find dozens of articles on using it.

Code Building

Building the code is really just a small part of the total project effort even though it's what most people equate with the whole process since it's the most visible. Other pieces equally or even more important include what we have already gone over above namely requirements, architecture, analysis, design, and testing. A best practice for building code involves daily builds and testing.

Best coding evolves from following proper coding standards and guidelines. Appropriate Comments for each and every line of code makes code maintainability much easier. A best code should have reusable components.A brief description of the aforementioned points is given below.

Testing

Main article: Software testing

Testing is an integral part of software development that needs to be planned. It is also important that testing is done proactively; meaning that test cases are planned before coding starts, and test cases are developed while the application is being designed and coded.

Deployment

Main article: Software deployment

Deployment is the final stage of releasing an application for users.

See also

• Best practice
• List of tools for static code analysis
• Motor Industry Software Reliability Association (MISRA)
• Software Assurance

References

• Harbison, Samuel P.; Steele, Guy L.. C - A Reference Manual. ISBN 978-0130895929. 
• Enhancing the Development Life Cycle to Product Secure Software, V2.0 Oct. 2008 describes the security principles and practices that software developers, testers, and integrators can adopt to achieve the twin objectives of producing more secure software-intensive systems, and verifying the security of the software they produce.
• Dutta, Shiv; Hook, Gary (June 26, 2003). "Best practices for programming in C". developerWorks. IBM. http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html. Retrieved January 21, 2010. 

External links

• Code example by Johan Bezem
• MISRA for C
• MISRA for C++