Code quality is an abstract concept again, and can be defined may ways depending on how you perceive quality. A good discussion of the many aspects of code quality can be found on Wikipedia at http://en.wikipedia.org/wiki/Software_quality
Some general high level objectives for software quality could be considered to be:
- Conformance to requirements
- Scalability
- Correctness
- Completeness
- Absence of Bugs
- Fault tolerance
- Extensibility
- Maintainability
- Documentation
At a code quality level, some general good guidelines would be:
- Readability
- Code should be simple to read, even without comments
- Class, method, and variable names should be expressive and unambiguous
- Functional intent should be easily understood
- Ease of Maintenance, Testing and Debugging
The degree of effort required to maintain, test and debug an application is a strong indication of the quality of the code and architecture. As the great majority of the cost of an application is actually composed of these three activities, these should be primary considerations
- Low Complexity
Complex code is rarely complex because the business functionality it implements is complex. Most software complexity comes through poorly designed and implemented code, over analysis of the problem, or adding additional functionality for requirements that do not yet exist.
- Low Resource Consumption
Poorly written code will not take account of resource usage, for example it will not cache information it could cache, or it will create new objects when it did not need to. These issues lead to hard to maintain applications when deployed and used.
To achieve these objectives, some basic principles of development and design can be applied. These have been referenced elsewhere, but are repeated here for clarity:
- Single Responsibility Principle
There should never be more than one reason for a class to change
- Liskov Substitution Principle
Methods that use references to base classes should be able to use derived classes without knowing they are doing so
- Open Closed Principle
Software entities (classes, modules, methods) should be open for extension but closed for modification
- Interface Segregation Principle
Clients should not be forced to depend upon interfaces they do not use
- Dependency Inversion Principle
High level modules should not depend upon low level modules, they should both depend upon abstractions
Abstractions should not depend upon details, details should depend upon abstractions
- Principle of Least Surprise (sometimes known as Principle of Least Astonishment)
The result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues
- Separation of Concerns
The application should be broken into components that overlap in functionality as little as possible
An assessment of code against these core principles should give a developer a good basis for assessment of the quality of a code base.