Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
What Determines High Quality Code?

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

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.

Posted 05-16-2008 2:59 PM by Jak Charlton



gOODiDEA.NET wrote Interesting Finds: 2008.05.18
on 05-17-2008 9:50 PM

Debug ASP.NET Tips: What to gather to troubleshoot - part 3a - Crash revisited Using Process Explorer

gOODiDEA wrote Interesting Finds: 2008.05.18
on 05-17-2008 9:51 PM


Dew Drop - May 17, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - May 17, 2008 | Alvin Ashcraft's Morning Dew
on 05-17-2008 10:09 PM

Pingback from  Dew Drop - May 17, 2008 | Alvin Ashcraft's Morning Dew

Reflective Perspective - Chris Alcock » The Morning Brew #96 wrote Reflective Perspective - Chris Alcock » The Morning Brew #96
on 05-19-2008 3:01 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #96

Mark Morgan wrote re: What Determines High Quality Code?
on 05-19-2008 4:44 AM

What about high levels of test coverage?  Without this then surely your code is an obstacle to change wiating to happen.

Single Responsibility Principle » wrote Single Responsibility Principle »
on 05-21-2008 12:37 AM

Pingback from  Single Responsibility Principle »

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)