Code Quality terms

8 terms of 1506 total

✨ Because working code and good code are not the same thing

Code that works today but cannot be understood, tested, or modified tomorrow is a liability, not an asset. Code quality covers metrics, static analysis, design principles like SOLID and DRY, refactoring techniques, and the habits that separate codebases teams love from ones they dread maintaining. Good quality is not about perfection — it is about making the next change easier than the last.

More on Code Quality history · 6 references · key concepts

History

Software quality emerged as a formal discipline in the 1960s and 1970s, driven by failures in large aerospace and defense projects that exposed the cost of defects. Early pioneers like Barry Boehm and Tom Gilb established metrics and processes to measure and control quality systematically. The rise of object-oriented programming in the 1980s–1990s introduced new design patterns and principles (SOLID, DRY, KISS) aimed at reducing defects through better code structure. The 2000s saw the emergence of automated testing frameworks, continuous integration, and static analysis tools that made quality enforcement scalable. Today, quality is embedded throughout the development lifecycle—from design patterns and code reviews to metrics-driven refactoring, design-by-contract practices, and tooling that catches defects before deployment.

Key concepts

Code Smell
DRY Principle
KISS Principle
Coupling
Cohesion
Long Method
God Class
Dependency Injection

Best references

Refactoring: Improving the Design of Existing Code (2nd Edition) Martin Fowler's seminal work defining code smells, refactoring techniques, and design patterns. Essential reference for understanding quality metrics, God Classes, Long Methods, and systematic improvement strategies.
Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin's influential guide covering naming conventions, function design, error handling, and code organization. Foundational for readability metrics, DRY principle, and maintainability standards.
Design Patterns: Elements of Reusable Object-Oriented Software The Gang of Four's canonical reference for creational, structural, and behavioral patterns (Factory, Builder, Facade, Observer, etc.). Authoritative source for pattern-based quality improvements.
SOLID Principles - Object Oriented Design Comprehensive overview of the five principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) that underpin maintainable architecture and low coupling.
Cyclomatic Complexity and Related Metrics - IEEE Standard ISO/IEC 26550 standard defining cyclomatic and cognitive complexity measurements. Authoritative reference for code complexity metrics and quality thresholds.
The Pragmatic Programmer: Your Journey to Mastery Hunt & Thomas on practical quality practices including DRY, the Boy Scout Rule, and defensive programming. Bridges theory and real-world professional standards.

🧠 Logic graph · Code Quality

47 edges here

16 verbs used

50 terms touched

6 narratives

✦ Latest in Code Quality

Typed relationships here

Edges touching a Code Quality term.

Dependency Injection Applies Dependency Inversion Principle (DIP) 18h
Tell Don't Ask Principle Mitigates Anemic Domain Model (Anti-Pattern) 1d
Tell Don't Ask Principle Mitigates Feature Envy 1d
Static Methods & Properties Contrasts with Dependency Injection 2d
Guard Clause Pattern Often seen in Defensive Programming 3d

A value object requires immutability — its whole equality-by-value contract depends on state never changing after construction. PHP's readonly classes are a language-level mechanism that applies exactly that immutability by making every declared property readonly, so the value object's defining guarantee is enforced by the compiler rather than by convention. Immutability is the shared property that carries the conceptual requirement from value_object down to the concrete PHP feature that implements it.

Value Object · by means of · 🪢 Immutability → Readonly Classes (PHP 8.2)

PHP's readonly classes connect to the problem of side effects by means of immutability: marking a class readonly enforces that its properties can't be mutated after construction, which is exactly the property immutability uses to mitigate side effects like argument mutation and shared-state changes. The readonly mechanism is the concrete language feature that realizes immutability, and immutability in turn is what carries the predictability guarantee back to the side-effects concern. Without immutability as the bridge, readonly_classes is just a PHP syntax detail with no inherent reason to relate to the general quality problem of side effects.

Side Effects · by means of · 🪢 Immutability → Readonly Classes (PHP 8.2)

Type safety relates to type coercion mainly by means of strict_types: flipping on strict_types=1 is the concrete switch that turns PHP's silent scalar conversions into hard TypeErrors. So the quality goal of type safety actually attacks the coercion problem through this declaration — strict_types is what carries the enforcement from the abstract goal down to suppressing the specific runtime behavior, and without it the coercion keeps happening even with typed signatures present.

Type Safety in PHP (strict_types & Static Analysis) · by means of · 🪢 declare(strict_types=1) → Type Coercion