Coding best practices or programming best practices are a set of informal

Coding best practices or programming best practices are a set of informal, sometimes personal, rules (best practices) that many software developers-in computer programming-follow to improve software quality. Many computer programs must be robust and reliable for extended periods of time, so any rules must facilitate both initial development and later maintenance of source code by people other than the original authors.

In the ninety–ninety rule, Tom Cargill explains why programming projects often run late: "The first 90% of the code takes the first 90% of the development time. The last 10% takes another 90% of the time.5 Any guidance which can redress this lack of foresight is worth considering.

The size of a project or program has a significant effect on error rates, programmer productivity, and the amount of management needed.

As listed below, there are many attributes associated with good software. Some of these can be mutually contradictory (e.g. being very fast versus performing extensive error checking), and different customers and participants may have different priorities. Weinberg provides an example of how different goals can have a dramatic effect on both effort required and efficiency. Furthermore, he notes that programmers will generally aim to achieve any explicit goals which may be set, probably at the expense of any other quality attributes.

Sommerville has identified four generalized attributes which are not concerned with what a program does, but how well the program does it: Maintainability, dependability, efficiency and usability.

Weinberg has identified four targets which a good program should meet:

• Does a program meet its specification ("correct output for each possible input")?
• Is the program produced on schedule (and within budget)?
• How adaptable is the program to cope with changing requirements?
• Is the program efficient enough for the environment in which it is used?

This has identified seventeen objectives related to software quality, including:

• Clear definition of purpose.
• Simplicity of use.
• Ruggedness (difficult to misuse, kind to errors).
• Early availability (delivered on time when needed).
• Reliability.
• Extensibility in the light of experience.
• Brevity.
• Efficiency (fast enough for the purpose to which it is put).
• Minimum cost to develop.
• Conformity to any relevant standards (including programming language-specific standards).
• Clear, accurate and precise user documents.

Prerequisites
Before any coding starts, the various prerequisites should have been done-or at least advanced far enough-to provide a sound basis for the coding. Unless these different prerequisites are met, the software is likely to be unsatisfactory-even if the software is finished.

From Meek & Heath: "What happens before one gets to the coding stage is often of crucial importance to the success of the project."

The pre-requisites below cover such matters as:

How is the development structured? (life cycle)
What is the software meant to do? (requirements)
What is the overall structure of the software system? (architecture)
What is the detailed design of individual components? (design)
What is the choice of programming language(s)?
For tiny uncomplicated projects, this may be sufficient to intermingle architecture with design and follow a very basic life cycle.

Life cycle
Main article: Software development methodology
A software development methodology is a framework that is used to structure, plan, and control the life cycle of a software product. Common methodologies include waterfall, prototyping, iterative and incremental development, spiral development, agile software development, rapid application development, and extreme programming.

The waterfall model is a sequential development approach; in particular, it assumes that the requirements can be completely defined at the start of a project. However, McConnell quotes three studies that indicate that, on average, requirements change by around 25% during a project. The other methodologies mentioned above all attempt to reduce the impact of such requirement changes, often by some form of step-wise, incremental or iterative approach. Different development environments may therefore call for different methodologies.

Agile software development has gained popularity since it was first established back in the year 2001, driven through active demand by software developers looking for an iterative and collaborative manner of developing software.

Requirements
Main article: Requirements engineering
McConnell says: "The first prerequisite you must meet before you start building is a clear statement of the problem the system is supposed to solve.

Meek and Heath stress that this should be clear, complete, precise, and unambiguous and in writing: that is the target to aim for. Note that it probably cannot be attained, and the target will probably change anyway (see previous section).

Sommerville distinguishes between less detailed user requirements and more detailed system requirements. He also distinguishes between functional requirements (e.g. update a record) and non-functional requirements (e.g. response time must be less than 1 second).

Software architecture is concerned with deciding what has to be done and which program component is going to do it (how something is done is left to the detailed design phase below). This is particularly important when a software system contains more than one program since it effectively defines the interface between these various programs. It should include some consideration of any user interfaces as well, without going into excessive detail.

Any non-functional system requirements (response time, reliability, maintainability, etc.) need to be considered at this stage.

The software architecture is also of interest to various stakeholders (sponsors, end-users, etc.) since it gives them a chance to check that their requirements can be met.

The primary purpose of design is to fill in the details which have been glossed over in the architectural design. The intention is that the design should be detailed enough to provide a good guide for actual coding, including details of any particular algorithms to be used. For example, at the architectural level, it may have been noted that some data has to be sorted, while at the design level, it is necessary to decide which sorting algorithm is to be used. As a further example, if an object-oriented approach is being used, then the details of the objects must be determined (attributes and methods).

Choice of programming language(s)
Mayer says: "No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes. Understanding the problem and associated programming requirements is necessary for choosing the language best suited for the solution."[

From Meek & Heath: "The essence of the art of choosing a language is to start with the problem, decide what its requirements are, and their relative importance since it will probably be impossible to satisfy them all equally well. The available languages should then be measured against the list of requirements, and the most suitable ) or least unsatisfactory) chosen.

It may be that different aspects of the problem call for different languages. If the languages, or more precisely their compilers, allow for it, it may even be possible to mix routines written in different languages within one and the same program.

Even when there is no choice as to which programming language is to be used, McConnell provides some advice: "Every programming language has strengths and weaknesses. Be aware of the specific strengths and weaknesses of the language you're using.

Coding standards
Main article: Coding conventions
This section is also really a pre-requisite to the actual coding, as McConnell explains : "Establish programming conventions before you start programming. It's practically impossible to change code to conform later."[19]
As listed near the end of coding conventions, there are different conventions for different programming languages, so it may be counterproductive to apply the same conventions across different languages. Also, notice that there is no single coding convention for any programming language. Every organization has its own coding standards for a particular kind of software project. It is therefore very important that a programmer will choose or develop a certain set of coding guidelines before the start of a software project. Some of the coding conventions are generic and may not relate to each and every software project developed in a particular programming language.

The usage of conventions is of high importance when a given project involves more than one programmer-projects having thousands of programmers are not unheard of. A programmer obviously finds it much easier to read code written by somebody else if all code follows the same conventions.

For some examples of poor coding conventions, Roedy Green has a long (tongue-in-cheek) article on how to write unmaintainable code.
 
Commenting
Commenting of code usually gets thrown to the back because of time constraints or eager programmers who want immediate returns of their code. Comments have been found to be better left behind as by coders working as a team because it usually follows cycles, or more than one person may work on a particular module. A little commenting can reduce the cost of knowledge transfer between the developers working on the same module.

One commenting practice initially in computing is leaving a short description of the following in remarks: Name of the module, Purpose of the Module, Description of the Module, Original Author, Modifications, Authors who modified code with description on why it was modified. The "description of the module" shall be as concise as possible but not at the expense of clarity and completeness.

However, the last two have mostly become obsolete with the introduction of revision control systems. Changes and their ownership can be tracked trustfully using such tools instead of comments.

Also, if complicated logic is being used, then it is a good practice to leave a comment "block" near that part so some other programmer can understand what exactly is happening.

Unit tests can also be another form of documentation on how the code is meant to be used.

Naming conventions
See also: Hungarian notation
Good use of naming conventions is seen as good practice. Sometimes programmers tend to use X1, Y1, etc. for variables and then never get round to replacing them with proper ones. Confusion results.
It is generally good practice to use descriptive names.

Example: An input variable, as parameter, for the weight of a truck can be named as: TrkWeight, TruckWeightKilograms or Truck_Weight_Kilograms, but TruckWeightKilograms (See Pascal case naming of variables) is often to be preferred as it would be instantly recognizable, but naming convention is not always consistent between projects and/or companies.

Easy to understand code
The code the programmer is writing should be simple. Difficult logic for achieving a simple thing should be kept to a minimum since the code might be modified by another programmer in the future. The logic one programmer implemented may not make perfect sense to another. So, always keep the code as simple as possible.

Portability
Program code should not contain "hard-coded" (literal) values referring to environmental parameters, like absolute file paths, file names, user names, host names, IP addresses and URLs, UDP/TCP ports. Otherwise the application will not run on a host which has different design than anticipated. A cautious programmer can parametrize such variables and set them for the hosting environment outside of the application proper, ex for example, in property files on an application server, or even in a database. Compare the mantra of a "single point of definition"

As an extension, resource files such as XML files should also contain variables and not literal values otherwise, it is not going to be portable to any other environment without editing the XML files. For instance, in the case of a J2EE application running in an application server, such environmental parameters may be defined within the scope of the JVM and the application should retrieve values from there.