= Code Quality Evaluation Guidelines =
[[TOC]]

== General Requirements ==

The general quality requirements are defined here as attributes of the solution that is to be evaluated ("The solution must be ...").

These attributes are grouped in four quality "levels" - a higher level representing a higher quality standard. 

Projects can refer to these levels to define minimum quality goals, to prioritize certain quality aspects vs. other requirements, or to define an iterative approach of continuous quality improvement.

In order to pass a level, all criteria of this level and all previous levels must be met.

||=Level=||=Priority (MoSCoW)=||=Key Attributes=||=Description=||
||0 - '''Experimental'''||-||-||any solution that does not (yet) meet all criteria of level 1||
||1 - '''Minimal'''||Must||valid, correct, safe||minimum standard for any solution||
||2 - '''Appropriate'''||Should||usable, maintainable, secure||minimum standard for production use||
||3 - '''Good'''||Can||integrated, configurable, robust||long-term development goals||
||4 - '''Optimal'''||Want||efficient, scalable, interoperable||optimization and enhancement goals||
=== Level 1: Minimal ===

==== Valid ====

''"Writing the right code"''

  * The specified solution solves the targeted problem and meets the minimum functional requirements
          
  * The required input data are available in the target scenario
        
  * The user actions required to apply and/or use the solution or its responses are ''possible'' in the target scenario
          
  * All dependencies of the feature set are resolvable, and hardware and infrastructure requirements can be met in the target scenario

==== Correct ====

''"Writing the code right"''

  * Processing does not fail for any valid input data or user action.
          
  * All responses are correct for the respective input data or user actions according to the specification

==== Safe ====


  * The solution does not break functionality of the application (except for functionality it replaces)
          
  * All processing always ends with a valid database status regardless whether it succeeds or fails

  * All failed processes are effectively removed from the system and their transactions properly rolled back
          
  * The solution effectively prevents uncontrolled indefinite object or process proliferation

  * The solution always returns to a defined system status after a failure so that the application remains accessible

=== Level 2: Appropriate ===

==== Secure ====

  * The solution applies all relevant system configurations for authentication, authorization and accounting (AAA) appropriately and correctly.

  * The solution does not allow the user to perform actions or initiate processes beyond the intended functionality.

==== Usable ====

  * The solution ''can'' be used by the intended user group in the target scenario, i.e. the users can:
    - discover and access the features
    - understand and perform the required user actions
    - understand and control the consequences of actions
    - understand and provide the required type, quality and format of input data
    - discover and access the results, and apply them to achieve their goals
==== Maintainable ====

  * The design of the solution does not obstruct diagnostics of defects

  * The code is structured in a way that the processing flow can easily be determined from it

  * All names used in the code are either self-explaining or sufficiently explained in comments

  * Internal critical dependencies are clearly documented in comments at their starting point
=== Level 3: Good ===

==== Integrated ====

  * The solution applies the application framework appropriately and correctly

  * The data structures defined in the solution are consistent with the global application data model

  * The solution interoperates appropriately and correctly with other system components

  * The solution applies the application's global design and style guidelines
==== Configurable ====

  * The solution can be easily and safely turned on and off without inadvertent side-effects

  * The solution applies global configuration settings correctly and consistently

  * Processing parameters, behavior and/or appearance of the solution can be adapted to requirements variations using configuration patterns separate from its core code
==== Robust ====

  * The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations

  * The solution detects invalid configurations and prevents any inadvertent effects that could result from them
=== Level 4: Optimal ===

==== Efficient ====

  * The solution provides acceptable performance with the minimum available hardware/infrastructure resources in the target scenario

  * The solution can utilize hardware/infrastructure enhancements to provide better performance
==== Scalable ====

  * The solution can handle/adapt to varying problem sizes (amount of data, frequency of events) without failure, inconsistent behavior or significant loss of performance

  * The solution can be applied in any number of concurrent instances (given the appropriate hardware and infrastructure) without failure, inconsistent behavior or significant loss of performance
==== Interoperable ====

== Advanced Criteria ==

The following ''advanced'' quality criteria that can be used to compare different solutions, or to define quality roadmaps for particular feature sets beyond the standard criteria.

Advanced quality criteria do not apply equally in all use-cases - in certain cases they may even constitute anti-patterns.

In any case, advanced criteria do not enhance the general quality level of a solution: a level-3 solution is still of better quality than a level-2 solution - regardless how many advanced criteria the level-2 solution meets.

=== Stable ===
=== Appealing ===
=== Flexible ===
=== Standardized ===
=== Extensible ===
=== Generic ===
=== Customizable ===