A reference from Weave

Find a term

Understand maintainability, code structure, and the costs of decisions that make future changes harder. Learn what quality signals can and cannot establish.

Terms beginning with C

20 terms

  • Cause-effect graphing

    Cause-effect graphing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Change-proneness

    The tendency of a component to be modified repeatedly within a defined period.

    Code quality and technical debt

  • Characterization test

    Characterization test is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Checklist-based testing

    Checklist-based testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Code age

    The elapsed time since a selected code element was last modified or introduced.

    Code quality and technical debt

  • Code archaeology

    Code archaeology is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Code coverage

    Code coverage is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Code ownership concentration

    The degree to which changes to a code area are made or reviewed by a small set of contributors.

    Code quality and technical debt

  • Code quality gate

    An automated condition that must pass before a change can advance in a delivery workflow.

    Code quality and technical debt

  • Cognitive complexity trend

    The change over time in a codebase’s cognitive complexity measurements.

    Code quality and technical debt

  • Combinatorial testing

    Combinatorial testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Compatibility testing

    Compatibility testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Compliance debt

    Compliance debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Component testing

    Component testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Configuration drift debt

    Configuration drift debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Continuous testing

    Continuous testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Control-flow graph

    A graph that represents the possible paths of execution through a program.

    Code quality and technical debt

  • Coupling between objects

    A count of relationships a class or object has with other classes or objects.

    Code quality and technical debt

  • Cross-browser testing

    Cross-browser testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Cyclomatic complexity density

    Cyclomatic complexity normalized by a measure of code size.

    Code quality and technical debt