Code Quality Standards

Measuring Code Quality

Development teams can use code quality standards to evaluate the structural quality of software ahead of each release. By applying 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 measures are designed to be automated on source code through static analysis and provide an industry-wide foundation for benchmarking, setting quality targets, providing visibility, and tracking improvement progress.

Built on MITRE Common Weakness Enumeration

Each code quality measure for Reliability, Performance Efficiency, Security, and Maintainability is comprised of a set of weaknesses (CWEs) in the MITRE Common Weakness Enumeration (CWE). The MITRE CWE is a reference point for developers and tools and codifies over 800 known software weaknesses. The coding rules enshrined in CISQ standards include such CWEs as SQL Injection and Buffer Overflow. CISQ identified the most critical and impactful CWEs and standardized them for automation under each quality characteristic.

Download a list of the CWEs in each code quality measure.

SUPPLEMENTING ISO 25000 BY MEASURING QUALITY AT THE SOURCE CODE

The ISO/IEC 25000 series of standards, also known as SQuaRE (System and Software Quality Requirements and Evaluation), contains a framework to evaluate software product quality. ISO/IEC 25010 defines a set of eight software quality characteristics, or system “-ilities,” i.e. security, reliability, and maintainability. ISO/IEC 25023 describes how to apply the quality characteristics to measure product quality. However, the measures defined in 25023 largely measure quality at the behavioral level rather than at the level of specific quality problems in the source code. To supplement the level of measurement in 25023, CISQ defined source code level measures of four quality characteristics — ReliabilityPerformance EfficiencySecurity, and Maintainability as outlined above. Dr. Bill Curtis, Founding Executive Director of CISQ, is the American lead on ISO 25000 and we seek to supplement ISO 25000 with actionable, automated standard measures of quality.

Coverage at the Unit and System Level

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

Software Quality Characteristic Coding Practices Unit Level Architectural Practices System Level
Reliability
  • 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
Performance Efficiency
  • 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
Security
  • 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
Maintainability
  • 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