Clean Code and Maintainability Engineering

Clean-code discussions often begin with naming, indentation, and short functions. Those details matter, but the engineering problem is deeper: how quickly can an engineer who did not write the code form a correct model of its behavior, how narrowly can a change be contained, and how can we demonstrate that behavior was not broken?

These notes treat clean code as a maintenance-cost and change-risk problem rather than an aesthetic preference. Sources used in the original 2015 context and Java practices used in the 2026 update are not presented as if they belonged to the same period. The examples use modern Java syntax, but their purpose is to expose design decisions rather than teach Java.

Process models and requirements management belong to Software Engineering; verification and validation belong to Software Testing Engineering; vulnerability classes belong to Secure Software Engineering.

Unit 1: A Measurable Definition of Code Quality

Quality is a set of criteria, not an adjective

"Good code" is not a one-dimensional judgment. ISO/IEC 25010:2011, the edition current when the first version of these notes was prepared, described product quality through eight characteristics. The second edition published in 2023 reorganized the model and defines nine product-quality characteristics. A 2015 discussion and a 2026 update should therefore not be read as if they used exactly the same edition and terminology.

For clean-code work, maintainability is central. Correct output today is not enough; a system must also support safe modification, analysis, and verification.

"This code is dirty" is not measurable. "Changing this business rule requires modifying six classes and three configuration files" defines an engineering problem that can be investigated.

Maintenance economics

Code is written relatively few times and read many times. A shortcut that saves minutes during initial implementation can impose repeated cognitive cost over years of maintenance. The reverse also matters: adding allocations, copying, or indirection to a hot path only for visual cleanliness can be a real cost.

The objective is therefore not the prettiest code. It is a defensible total engineering cost.

Metrics guide attention

Cyclomatic complexity, dependency count, file size, and churn are useful signals, but none directly measures whether a human understands a design.

Two functions can have the same complexity score while one naturally expresses the domain and the other is an accidental state machine. A metric identifies an area for inspection; engineering judgment explains why it is or is not justified.

Unit 2: Reading Cost and Naming

A name is a function of scope

Identifier length should be considered together with visible scope. i can be perfectly clear in a three-line loop while d can be unacceptable as long-lived class state.

Problematic:

public List<User> get(final List<User> u) {
    final List<User> r = new ArrayList<>();
    for (final User x : u) {
        if (x.status() == 1) {
            r.add(x);
        }
    }
    return r;
}

A domain-oriented form:

public List<User> findActiveUsers(final List<User> users) {
    final List<User> activeUsers = new ArrayList<>();
    for (final User user : users) {
        if (user.isActive()) {
            activeUsers.add(user);
        }
    }
    return activeUsers;
}

The improvement does not come from ArrayList or the loop. It comes from removing the backward-navigation cost imposed by get, u, r, x, and status() == 1.

Searchability

A stable name for a meaningful concept reduces codebase-scale search cost. Raw values do not carry that property:

if (elapsedSeconds > 86400) {
    archive();
}

Naming the domain value exposes intent:

private static final long SECONDS_PER_DAY = 86_400;

if (elapsedSeconds > SECONDS_PER_DAY) {
    archive();
}

Not every literal is a magic number. The 1 in index + 1 already means "the next index" in many contexts; NEXT_INDEX_OFFSET would add noise rather than information.

One concept, one word

If the same operation is called load, fetch, and read in different areas, readers reasonably assume the words represent different contracts. If the behavior is truly different, different names are correct. If not, a shared vocabulary is cheaper.

Naming is not about using more words. It is about reducing incorrect branches in the reader's mental model.

Unit 3: Function Boundaries and Levels of Abstraction

Responsibility is not line count

A function boundary is not determined by its number of lines. The stronger question is whether it operates at one coherent decision level.

Mixed responsibilities:

public void process(final Order order) {
    if (order == null) {
        throw new IllegalArgumentException("order");
    }
    if (order.total().signum() <= 0) {
        throw new IllegalStateException("Order total must be positive");
    }

    repository.save(order);

    final String email = order.customer().email();
    if (email != null) {
        mailService.send(email, "Order saved");
    }
}

Separating boundaries exposes the high-level flow:

public void process(final Order order) {
    validate(order);
    repository.save(order);
    notifyCustomer(order);
}

private void validate(final Order order) {
    if (order == null) {
        throw new IllegalArgumentException("order");
    }
    if (order.total().signum() <= 0) {
        throw new IllegalStateException("Order total must be positive");
    }
}

private void notifyCustomer(final Order order) {
    final String email = order.customer().email();
    if (email != null) {
        mailService.send(email, "Order saved");
    }
}

This is not a rule to make every function smaller. Dozens of micro-functions called once and understandable only from their call-site context can increase navigation cost.

Guard clauses and nesting

Deep nesting forces the reader to keep too many predicates active:

public void publish(final Media media) {
    if (media != null) {
        if (media.isReady()) {
            if (!media.isDeleted()) {
                publisher.publish(media);
            }
        }
    }
}

Guard clauses can reduce that active state:

public void publish(final Media media) {
    if (media == null || !media.isReady() || media.isDeleted()) {
        return;
    }
    publisher.publish(media);
}

The goal is not fewer lines; it is lower cognitive state.

Flag arguments

public void save(final User user, final boolean notify) {
    repository.save(user);
    if (notify) {
        notificationService.send(user);
    }
}

save(user, true) does not explain behavior. If these are genuinely different workflows, name them:

public void save(final User user) {
    repository.save(user);
}

public void saveAndNotify(final User user) {
    repository.save(user);
    notificationService.send(user);
}

A call such as setEnabled(boolean enabled) is different: the Boolean directly represents state. The smell appears when the Boolean acts as a selector hiding separate workflows.

Command-query separation

A method that looks like a query but mutates state creates a hidden side effect:

if (userRepository.existsAndMarkSeen(userId)) {
    continueProcessing();
}

If atomicity does not require one operation, the state transition can be made visible:

if (userRepository.exists(userId)) {
    userRepository.markSeen(userId);
    continueProcessing();
}

When one database operation is required for latency or atomicity, the combined behavior can still be correct; the method name should make that contract explicit.

Unit 4: Comments as a Contract with Code

Comments are not compiled

Comments are not automatically verified with the code. When implementation changes and prose does not, a stale comment can be more dangerous than no comment.

Weak comment:

// Continue if the user is active
if (user.status() == 1) {
    process(user);
}

Move the meaning into code:

if (user.isActive()) {
    process(user);
}

Rationale can belong in comments

Code can show what happens but not always why a measured exception must remain:

// A 64 KiB block produced the lowest measured p99 write latency on this device family.
// Re-benchmark on the same storage profile before changing this value.
private static final int WRITE_BUFFER_SIZE = 64 * 1024;

This comment does not repeat the code. It preserves the decision source and the condition for changing it.

Commented-out and dead code

With version control, long-lived commented-out code creates ambiguity without preserving unique information. The same applies to unreachable functions.

A TODO is useful when it contains a concrete exit condition:

// TODO: Remove this fallback after the provider's 2.4 timeout defect is no longer supported.

TODO: fix carries no decision and no completion criterion.

Unit 5: Modular Decomposition and Information Hiding

Hide the volatile decision

Parnas's criterion places module boundaries around design decisions likely to change rather than around execution steps. Ideally, changing one decision changes one localized area.

A business layer can depend on a stable boundary:

public interface ReportRepository {
    List<ReportRow> load(final ReportRange range);
}

public final class ReportService {
    private final ReportRepository repository;

    public ReportService(final ReportRepository repository) {
        this.repository = repository;
    }

    public List<ReportRow> generate(final ReportRange range) {
        return repository.load(range);
    }
}

The interface itself does not create quality. Adding an interface for every class with one stable implementation and no observed change axis can be structural noise.

Coupling and cohesion

A class that changes for unrelated reasons has low cohesion and often accumulates dependency directions. Dependency graphs can reveal such nodes, but high connectivity is not automatically bad: a stable central domain abstraction can legitimately have many edges.

The cost of premature abstraction

Two fragments should not be merged merely because they look similar. If the actual axis of change has not appeared yet, a common base type can tie unrelated behavior to the wrong contract.

Abstract repeated knowledge, not merely repeated text.

Unit 6: Error Handling and Error Contracts

Keep failure policy explicit

Java exceptions can separate failure flow from normal results, but they create non-local control transfer. The important question is where a failure becomes meaningful.

Returning null can spread checks to every caller:

public Media load(final long id) {
    return repository.findById(id);
}

If "not found" is exceptional at this layer, the contract can say so:

public Media load(final long id) {
    final Media media = repository.findById(id);
    if (media == null) {
        throw new MediaNotFoundException(id);
    }
    return media;
}

If "no result" is an ordinary outcome, Optional, an empty collection, or an explicit result type may be better. The rule is not "replace every null with an exception."

Add context where abstraction changes

Low-level failures should not leak arbitrarily across boundaries:

try {
    return jdbcRepository.load(id);
} catch (final SQLException e) {
    throw e;
}

A repository boundary can translate infrastructure detail into a repository contract:

try {
    return jdbcRepository.load(id);
} catch (final SQLException e) {
    throw new UserRepositoryException("Cannot load user " + id, e);
}

Mechanically wrapping every exception adds no value. Context belongs where the abstraction level changes.

Never swallow failure without policy

try {
    write(record);
} catch (final IOException ignored) {
}

The failure has not disappeared; only its visibility has. Logging and continuing is also not automatically correct. The caller's ability to distinguish success from failure is part of the contract.

Partial state

When work stops halfway, the remaining state must be defined. Database transactions, atomic file publication, message idempotency, and compensation solve different forms of partial progress. Error handling is therefore a state-management problem, not merely an exception-class choice.

Unit 7: Boundary Code and External Dependencies

Prevent external models from leaking inward

If a provider DTO circulates through the entire application, a provider field change becomes a core change.

A boundary can localize the dependency:

public interface PersonnelGateway {
    User findById(final String id);
}

public final class RestPersonnelGateway implements PersonnelGateway {
    private final RestClient restClient;

    public RestPersonnelGateway(final RestClient restClient) {
        this.restClient = restClient;
    }

    @Override
    public User findById(final String id) {
        final ExternalUser response = restClient.get()
            .uri("/users/{id}", id)
            .retrieve()
            .body(ExternalUser.class);

        return new User(response.id(), response.name(), response.department());
    }
}

The core never needs to know ExternalUser.

Do not wrap every dependency

A small stable standard library does not automatically need an application-specific wrapper. The value of a boundary is to localize volatility and replacement pressure.

Learning tests

Documentation and observed behavior are not the same thing. Small tests can encode assumptions about a third-party library and reveal whether an upgrade changes those assumptions.

Feathers's seam concept serves a related purpose in legacy code: find a substitution point before attempting broad restructuring.

Unit 8: How Testability Pressures Design

Testing difficulty is often a design signal

If one unit test requires a real database, filesystem, and network, the problem is not only the test harness. Dependencies are embedded in the behavior.

Embedded construction:

public final class ReportService {
    private final Repository repository = new OracleRepository();
    private final Clock clock = Clock.systemUTC();

    public Report create() {
        return repository.load(LocalDate.now(clock));
    }
}

Supplying dependencies externally makes behavior controllable:

public final class ReportService {
    private final Repository repository;
    private final Clock clock;

    public ReportService(final Repository repository, final Clock clock) {
        this.repository = repository;
        this.clock = clock;
    }

    public Report create() {
        return repository.load(LocalDate.now(clock));
    }
}

The test can freeze time:

final Clock clock = Clock.fixed(
    Instant.parse("2026-09-08T09:00:00Z"),
    ZoneOffset.UTC
);
final ReportService service = new ReportService(repository, clock);

This does not imply that every helper needs injection. Wrapping stable side-effect-free utilities can create more design cost than test value.

Tests should protect behavior

A test coupled to implementation detail can break during refactoring even when behavior is unchanged. The long-term value of a test is that it preserves externally meaningful behavior while internal structure evolves.

One of TDD's durable design effects is that it forces the interface to be considered from the caller's perspective.

Unit 9: Measurement, Static Analysis, and Automation

Tool boundaries

Static analysis inspects code without running it. Depending on language and analyzer it can detect unused values, some resource leaks, suspicious control flow, type problems, and risky language constructs. It cannot by itself prove domain correctness or a p99 latency target.

Cyclomatic complexity

McCabe's metric for a single connected control-flow graph is:

V(G) = E - N + 2

Its value is as a branching signal, not an automatic quality judgment.

A domain decision can sometimes be collected into one named location:

public boolean isProcessable(final Media media) {
    return media.status() == MediaStatus.ACTIVE
        && media.durationSeconds() > 0
        && !media.deleted();
}

The method does not magically remove complexity. It localizes one decision.

Automate repeatable rules

During my Baykar internship I worked on programming standards and built a source-code analyzer that automated part of the rule set. It did not rely on naive text search; it processed the source character by character and distinguished comments, strings, preprocessor text, and ordinary code.

The same character sequence can mean different things in different lexical states. A comment delimiter inside a string is not a comment, and an assignment operator in a condition requires context. I later normalized findings from cppcheck and splint into the same result model. The durable lesson was simple: a deterministic rule should not depend on human memory alone. Historical details are in the Baykar software internship record.

Code review

Once formatting and mechanical checks are automated, review can focus on rationale: why the change exists, which alternative was rejected, which boundary cases were considered, whether dependency direction is correct, and where new risk was introduced.

Unit 10: The Limit of Readability in Concurrent Code

A thread-safe primitive is not a thread-safe workflow

Mutable shared state is the central cost of concurrent code. Even a counter can race:

private long processed;

public void markProcessed() {
    processed++;
}

AtomicLong makes an individual increment safe:

private final AtomicLong processed = new AtomicLong();

public void markProcessed() {
    processed.incrementAndGet();
}

But a compound decision can still race:

if (processed.get() < limit) {
    processed.incrementAndGet();
    processItem();
}

Each individual operation is thread-safe while the invariant "never exceed the limit" spans both calls. Synchronization must protect the invariant, not merely the primitive.

Reduce sharing

The cheapest lock is the lock you do not need. State local to a task requires no synchronization. Immutable objects also reduce mutation races after publication.

Lock scope

Large critical sections simplify reasoning but increase contention. Tiny sections can reduce contention while accidentally splitting one invariant. The boundary should be chosen from correctness first and validated with profiling and load tests.

Readable concurrent code is not code that merely looks smooth. Ownership, invariants, and synchronization boundaries must be visible.

Unit 11: Rules Depend on Context

Performance-sensitive code

Abstraction layers, intermediate objects, and collection transformations can create real cost on hot paths.

For example:

public List<Sample> positiveSamples(final List<Sample> samples) {
    return samples.stream()
        .filter(sample -> sample.value() > 0)
        .toList();
}

can be clear and appropriate in ordinary application code. In an allocation-sensitive path processing millions of samples, in-place work or preallocated buffers can be better.

The rule is measurement, not ideology. Sacrifice readability only where a measured hot region justifies it.

Real-time and embedded constraints

Worst-case execution time, queue bounds, blocking behavior, and allocation policy can matter more than average throughput. In such systems, making resource bounds visible is part of readability.

Historical context

A strange decision in old code may reflect the compiler, hardware, and runtime constraints of its period. Before removing an old optimization, identify the original constraint.

Unit 12: Formatting as a Visual Contract

Vertical and horizontal structure

Formatting is not merely aesthetic. Related expressions should appear related, and separate concepts should be visually separated.

Dense form:

if(user!=null&&user.isActive()&&rights.contains(user.id())&&!blocked.contains(user.id()))process(user);

Visible boundaries:

if (user != null
        && user.isActive()
        && rights.contains(user.id())
        && !blocked.contains(user.id())) {
    process(user);
}

Multi-line layout is not always better. A short natural expression can remain on one line. The goal is not to worship formatter output; it is to make relationships visible.

Team consistency

One mechanically enforced format across a codebase is cheaper than several individually good styles. Formatter and linter issues should not consume the main code-review discussion.

Unit 13: Objects, Data Structures, and the Location of Behavior

Private fields are not sufficient abstraction

A class that exposes direct getters and setters for every field can still leak representation.

Anemic account:

public final class Account {
    private BigDecimal balance;

    public BigDecimal getBalance() {
        return balance;
    }

    public void setBalance(final BigDecimal balance) {
        this.balance = balance;
    }
}

Behavior-oriented account:

public final class Account {
    private BigDecimal balance;

    public Account(final BigDecimal balance) {
        this.balance = balance;
    }

    public void withdraw(final BigDecimal amount) {
        if (amount.signum() <= 0) {
            throw new IllegalArgumentException("amount");
        }
        if (balance.compareTo(amount) < 0) {
            throw new InsufficientBalanceException();
        }
        balance = balance.subtract(amount);
    }

    public BigDecimal balance() {
        return balance;
    }
}

The withdrawal invariant remains inside the object.

A DTO can be intentionally behaviorless

The same rule should not be applied mechanically to transfer types:

public record PersonnelResponse(
    String id,
    String name,
    String department
) {
}

Its job is to carry data. Not every data structure should become a rich domain object. Objects and data structures optimize different kinds of change.

The Law of Demeter

This chain teaches the caller internal topology:

final String city = order.customer().address().city().name();

If the behavior belongs to the domain object, a narrower contract can be used:

final String city = order.deliveryCity();

Fluent APIs and plain DTO traversal are not automatic violations:

request.header("Accept", "application/json")
    .timeout(timeout)
    .send();

The issue is not the number of dots. It is the amount of internal representation knowledge required from the client.

Unit 14: Separating System Construction from System Use

Construction and use are different responsibilities

Business logic that constructs infrastructure dependencies couples policy to mechanism:

public final class ReportService {
    private final Repository repository = new OracleRepository();
    private final Clock clock = Clock.systemUTC();
}

External construction separates those decisions:

public final class ReportService {
    private final Repository repository;
    private final Clock clock;

    public ReportService(final Repository repository, final Clock clock) {
        this.repository = repository;
        this.clock = clock;
    }
}

A composition root assembles concrete components:

final Repository repository = new OracleRepository(dataSource);
final Clock clock = Clock.systemUTC();
final ReportService reportService = new ReportService(repository, clock);

Spring or another DI container can automate this wiring. Dependency Injection and Dependency Inversion are not the same concept. A container does not automatically repair incorrect dependency direction.

Cross-cutting concerns

Transactions, authorization, logging, and telemetry can cut across many classes. Interceptors, proxies, and aspects can localize policy but can also create invisible runtime behavior. In critical systems, traceability of side effects matters as much as removing duplication.

Unit 15: Simple Design and Successive Refinement

The first correct solution need not be the final design

Behavior can first be made correct and verifiable, then improved through small transformations. A broad rewrite mixes behavioral debugging with structural change in one diff.

Repeated text is not always repeated knowledge

Two calculations can encode the same business rule:

final BigDecimal invoiceTax = invoiceTotal.multiply(new BigDecimal("0.20"));
final BigDecimal refundTax = refundTotal.multiply(new BigDecimal("0.20"));

The decision can be named:

private static final BigDecimal VAT_RATE = new BigDecimal("0.20");

public BigDecimal calculateVat(final BigDecimal amount) {
    return amount.multiply(VAT_RATE);
}

But if two similar formulas belong to different regulations or product policies and evolve independently, merging them because the lines look alike creates the wrong abstraction.

Four practical priorities

A useful ordering is: keep behavior verifiable, reduce repeated knowledge, make intent expressive, and keep unnecessary structure low.

The last priority must not defeat the others. Mixing responsibilities to reduce class count is as mechanical as creating an interface and factory for every class.

Unit 16: Code Smells as Diagnostic Signals

A smell is not a defect verdict

Long parameter lists, flag arguments, feature envy, dead functions, repeated conditions, and oversized classes are inspection signals. Context determines whether they create actual change cost.

Feature envy

A method that spends most of its effort reading another object's state may live in the wrong place:

public BigDecimal discount(final Customer customer) {
    if (customer.orders().size() > 20
            && customer.totalSpend().compareTo(VIP_LIMIT) > 0) {
        return VIP_DISCOUNT;
    }
    return BigDecimal.ZERO;
}

If the policy belongs to the customer's lifecycle:

public BigDecimal discount() {
    if (orders.size() > 20 && totalSpend.compareTo(VIP_LIMIT) > 0) {
        return VIP_DISCOUNT;
    }
    return BigDecimal.ZERO;
}

can be more local. If discount policy is a separate marketing rule that changes independently, moving it into Customer increases coupling instead. The smell does not decide the move.

Centralize boundary conditions

Equivalent end-of-range logic written differently can drift:

if (index < items.size() - 1) {
    index++;
}

if (selected + 1 < items.size()) {
    selected++;
}

If these are truly the same rule:

private boolean hasNext(final int index, final int size) {
    return index + 1 < size;
}

can centralize it.

Hidden temporal coupling

If start() is invalid before initialize(), do not leave that requirement only in documentation. A constructor, factory, or explicit state model should make invalid call sequences difficult or impossible where practical.

Unit 17: Execution Models and Shutdown in Concurrent Systems

Concurrency is not synonymous with speed

Concurrency separates what is done from when it is done. I/O-heavy workloads can overlap waiting and improve throughput. CPU-bound workloads can instead suffer from contention, context switching, and cache pressure.

Modern Java virtual threads can reduce thread cost for large numbers of I/O-heavy tasks:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (final Task task : tasks) {
        executor.submit(() -> process(task));
    }
}

This does not solve races. Virtual threads change the cost model of execution units; mutable shared state, backpressure, and invariants remain design problems.

Producer-consumer and backpressure

If producers outrun consumers, an unbounded queue only converts latency into memory growth. Queue capacity, rejection, slowing, or load-shedding policy must be part of the design. "Asynchronous" does not mean "unbounded."

Shutdown is a protocol

A service that starts but cannot stop cleanly has an incomplete lifecycle:

public final class Worker implements AutoCloseable {
    private final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

    public void submit(final Runnable task) {
        executor.submit(task);
    }

    @Override
    public void close() {
        executor.shutdown();
    }
}

Real shutdown may require more than shutdown(): stop accepting work, finish or cancel in-flight tasks, preserve interruption, drain queues, and close resources within a defined time.

Concurrent testing is not proof

A concurrency test that passes once does not prove correctness. Different worker counts, repeated stress, scheduler pressure, and multiple platforms increase the number of interleavings explored.

A rare unexplained failure should not automatically be dismissed as "flaky." It can be evidence of a race. Stress testing is still not formal proof; it increases the probability of exposing failure.

General Conceptual Framework

Code quality is part of maintenance cost and change risk, not merely a style preference. Decomposition should follow the axis of change. A good boundary localizes a decision. Automation checks repeatable rules; review checks rationale.

Clean-code principles are contextual rather than absolute. Performance-sensitive, real-time, embedded, and safety-critical systems can place the tradeoff at different points. A deliberate exception should remain local and preserve the measured reason that justified it.

Distinctions worth preserving:

• Formatting is not the whole of readability.
• A short function is not proof of single responsibility.
• High test coverage is not proof of correct verification.
• Low cyclomatic complexity is not proof of understandable design.
• No static-analysis warning does not mean no defect.
• Many comments do not mean decisions are well documented.
• Refactoring is not a behavior change.
• A thread-safe primitive is not a thread-safe workflow.
• Dependency injection does not automatically produce correct dependency direction.
• Similar code is not always duplicated knowledge.
• Immutability reduces some defect classes but does not remove allocation cost.
• Virtual threads do not solve races or backpressure.

References

• David L. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1972. DOI
• Edsger W. Dijkstra. Go To Statement Considered Harmful. Communications of the ACM, 11(3), 1968. DOI
• Thomas J. McCabe. A Complexity Measure. IEEE Transactions on Software Engineering, SE-2(4), 1976. DOI
• Donald E. Knuth. Literate Programming. The Computer Journal, 27(2), 1984. DOI
• Meir M. Lehman. Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68(9), 1980. DOI
• Barbara H. Liskov; Jeannette M. Wing. A Behavioral Notion of Subtyping. ACM TOPLAS, 16(6), 1994. DOI
• Brian W. Kernighan; P. J. Plauger. The Elements of Programming Style, 2nd ed. McGraw-Hill, 1978.
• Frederick P. Brooks. The Mythical Man-Month. Addison-Wesley, 1975.
• Steve McConnell. Code Complete, 2nd ed. Microsoft Press, 2004.
• Kent Beck. Test-Driven Development: By Example. Addison-Wesley, 2002.
• Michael C. Feathers. Working Effectively with Legacy Code. Prentice Hall, 2004.
• Martin Fowler. Refactoring: Improving the Design of Existing Code, 2nd ed. Addison-Wesley, 2018.
• Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008.
• Robert C. Martin. The Clean Coder: A Code of Conduct for Professional Programmers. Prentice Hall, 2011.
• International Organization for Standardization. ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE). ISO, 2011. URL
• International Organization for Standardization. ISO/IEC 25010:2023 — Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model. ISO, 2023. URL