Code Quality terms
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
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.
✦ 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.
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.
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.
Low Cohesion
A class or module that does many unrelated things — high coupling's counterpart, making code hard to understand, test, and reuse.
3mo ago
Code Quality intermediate
Large Class
A class that has grown to accumulate too many responsibilities, fields, and methods — a sign it should be split into focused, cohesive classes.
3mo ago
Code Quality beginner
Law of Demeter
A design guideline: a method should only call methods on itself, its parameters, objects it creates, and its direct fields.
3mo ago
Code Quality intermediate
Law of Demeter — PHP Examples
The Law of Demeter (don't talk to strangers) limits method chains — each unit should call only its direct collaborators, not traverse object graphs.
3mo ago
Code Quality intermediate
Lazy Class
A class that doesn't do enough to justify its existence — the cost of understanding it exceeds the value it provides.
3mo ago
Code Quality beginner
Lines of Code (LOC) as a Metric
The simplest size metric — useful for normalising other metrics and tracking growth, but a poor quality indicator when used in isolation.
3mo ago
Code Quality beginner
Liskov Substitution Principle
1
Subtypes must be substitutable for their base types without altering the correctness of the program.
3mo ago
Code Quality intermediate
Long Method
PHP 5.0+
A function or method that is too long to understand in one reading — typically 20+ lines is a signal to split.
3mo ago
Code Quality beginner
Long Parameter List
A function or method with too many parameters — typically 4+ — making calls hard to read and easy to get wrong.
3mo ago
Code Quality beginner