Code Quality Standards

Development teams can use code quality standards to evaluate the structural quality of their software during each release. Acquisition and procurement teams can cite these standards in contract requirements with IT service providers and software partners to ensure the delivery of structurally sound software that is secure, resilient and easier to maintain. By applying code quality standards earlier in the software development lifecycle, a codebase can be carried over to other products, developed further, or open sourced with greater confidence, resulting in less technical debt and complexity.


The CISQ Automated Quality Characteristic Measures for Security, Reliability, Performance Efficiency and Maintainability are standards used to evaluate compliance with eighty-six well-established software engineering rules to ensure secure, reliable, efficient and easy to maintain software. The measures are designed to be automated through static source code analysis to identify critical weaknesses in the software that are severe enough that they need to be fixed. Combined with a software sizing measure, a density metric can be produced for each quality characteristic. Thresholds can be set for each characteristic to manage the quality of software being developed or delivered by a third party. The CISQ measures serve as the basis for the new Automated Technical Debt standard which estimates the future cost of corrective maintenance due to weaknesses remaining in source code at release.


The following table shows a snapshot of software engineering rules contained in the measurement of each quality characteristic at the code unit level and system level.




Software Quality Characteristic Coding Practices
Unit Level
Architectural Practices
System Level
  • Protecting state in multi-threaded environments
  • Safe use of inheritance and polymorphism
  • Resource bounds management, Complex code
  • Managing allocated resources, Timeouts
  • Multi-layer design compliance
  • Software manages data integrity and consistency
  • Exception handling through transactions
  • Class architecture compliance
  • Compliance with Object-Oriented best practices
  • Compliance with SQL best practices
  • Expensive computations in loops
  • Static connections versus connection pools
  • Compliance with garbage collection best practices
  • Appropriate interactions with expensive or remote resources
  • Data access performance and data management
  • Memory, network and disk space management
  • Centralized handling of client requests
  • Use of middle tier components vs. procedures/DB functions
  • Use of hard-coded credentials
  • Buffer overflows
  • Missing initialization
  • Improper validation of array index
  • Improper locking
  • Uncontrolled format string
  • Input validation
  • SQL injection
  • Cross-site scripting
  • Failure to use vetted libraries or frameworks
  • Secure architecture design compliance
  • Unstructured and duplicated code
  • High cyclomatic complexity
  • Controlled level of dynamic coding
  • Over-parameterization of methods
  • Hard coding of literals
  • Excessive component size
  • Duplicated business logic
  • Compliance with initial architecture design
  • Strict hierarchy of calling between architectural layers
  • Excessive horizontal layers
  • Excessive multi-tier fan-in/fan-out


In 2018 CISQ launched an Embedded Extensions working group that is working on software quality standards for embedded and real-time systems in such domains as avionics, automotive, medical equipment, and the Internet of Things (IoT).


Code quality standards from CISQ provide an industry-wide foundation for benchmarking, setting quality targets, providing visibility, and tracking improvement progress.



For guidance on applying CISQ standards, read these whitepapers:


U.S. Government IT acquisition examples: