DEV Community: Giovanna Moeller

The Single Responsibility Principle (SRP) of SOLID

Giovanna Moeller — Thu, 08 Feb 2024 21:44:26 +0000

Introduction

In this article, I will address the first principle of SOLID, known as the Single Responsibility Principle (SRP).

First, what is SOLID?

SOLID is an acronym representing five fundamental principles of object-oriented software design and architecture, identified by Robert C. Martin (Uncle Bob) around the 2000s. The acronym SOLID was introduced by Michael Feathers, after observing that the five principles could fit into this word.

Following these principles can result in a system that is more comprehensible, flexible, and modular, which is easy to scale, modify, and test.

Definition

The Single Responsibility Principle (SRP), the first of the five principles of SOLID, is a fundamental concept in object-oriented software development.

This principle states that a class should have only one reason to change, meaning it should be responsible for only one part of the software's functionality.

You should apply this principle not only to classes but also to functions, modules, etc.

An analogy for better understanding

Imagine a team in a restaurant. In this team, we have various functions: cooks, waiters, and the manager. Each of these team members has a unique responsibility. The cooks prepare the food, the waiters serve the food to the customers, and the manager takes care of the restaurant's administration. Imagine the chaos if a single person tried to perform all these tasks, it would generate a totally inefficient and confusing system.

Similarly, a class in software should specialize in a single functionality or responsibility. This makes maintenance easier, code comprehension better, and aids in reusability.

SRP in software development

Let's observe an example that violates the SRP. The class below deals with user details and at the same time manages the storage logic of those details.

class UserManager:
    def __init__(self, user_name, email):
        self.user_name = user_name
        self.email = email

    def change_user_email(self, new_email):
        # Logic to change the user's email

    def save_user(self):
        # Logic to save the user in the database

In this code, UserManager is responsible for both managing user details and the storage logic (data persistence). This violates the SRP, as we have more than one reason to modify the class.

To correct the SRP violation, we can divide the class into two: one to manage user details and another to handle data persistence.

class User:
    def __init__(self, user_name, email):
        self.user_name = user_name
        self.email = email

    def change_email(self, new_email):
        # Logic to change the user's email

class UserDataStorage:
    def save_user(self, user):
        # Logic to save the user in the database

Shall we see another example?

Below, we have a class that generates reports on products and also saves them in a file. This class does too much by dealing with both formatting and data persistence.

class ProductReport:
    def __init__(self, products):
        self.products = products

    def generate_report(self):
        # Logic to generate report

    def save_report(self):
        # Logic to save report

To adhere to the SRP, we can create a separate class for generating the report and another for saving the report to a file.

class ProductReportGenerator:
    def __init__(self, products):
        self.products = products

    def generate_report(self):
        # Logic to generate report

class ReportSaver:
    def save_report(self, report):
        # Logic to save report

Tips for applying the SRP to your project

Identify responsibilities: Analyze your classes to identify different responsibilities. Each responsibility is a potential axis of change.
Divide and conquer: If a class has more than one responsibility, consider dividing it into smaller classes, each with its own responsibility.
Code reuse: Classes with a single responsibility are easier to reuse because you can use them in different contexts without bringing unnecessary functionalities.
Testability: Classes focused on a single responsibility are easier to test because you do not have to deal with multiple functionalities during the testing of a specific functionality.

Conclusion

The Single Responsibility Principle is essential for sustainable and high-quality software development. Classes, functions, modules focused on a single responsibility ensure efficiency, maintainability, and clarity of code. By applying the SRP, you create a solid foundation for a robust software architecture, facilitating the evolution and maintenance of your project.

Thank you so much for reading this far. Find me on other social networks.

Generics in Swift: Expanding Flexibility and Code Reusability

Giovanna Moeller — Tue, 06 Feb 2024 21:04:09 +0000

Introduction

Generics are a powerful feature in Swift that allow for the creation of flexible, reusable, and type-safe code, avoiding duplication and enhancing clarity. In this article, I will explore the motivation behind using generics, introduce their syntax, and fundamental concepts such as generic functions, classes, and structs, type constraints, and share an interesting curiosity of the language: the relationship between generics and optionals.

Motivation

You might already know that Swift is a strongly typed language, meaning you must explicitly define the type of each variable, constant, parameter, and return value in your code.

Although Swift also has type inference functionality (where the compiler automatically deduces the type of a variable based on the value assigned to it), the types are still well defined. If you declare that a function receives a value of type String, you must pass a string and nothing else.

See below a function that returns the first element of an array:

let names = ["Paul", "Steve", "Anna"]

func firstElement(_ array: [String]) -> String? {
    return array.first
}

if let firstName = firstElement(names) {
    print(firstName)
}

In the example above, we are defining that the type of elements that should compose the array is String. And if I want to get the first element of an array of numbers? I would need to create another function:

let numbers = [5, 10, 15]

func firstElement(_ array: [Int]) -> Int? {
    return array.first
}

if let firstNumber = firstElement(numbers) {
    print(firstNumber)
}

A lot of code repetition, right? Well, without the use of generics, we would have to write multiple functions, one for each type, which leads to unnecessary code duplication.

Understanding Generics

Generics allow writing functions and types that can work with any type, maintaining the type safety that Swift brings us. The same problem of returning the first element of the array can be solved with generics, as follows:

let names = ["Gi", "Daniel", "Ana"]
let numbers = [5, 10, 15]

func firstElement<T>(_ array: [T]) -> T? {
    return array.first
}

if let firstName = firstElement(names) {
    print(firstName)
}

if let firstNumber = firstElement(numbers) {
    print(firstNumber)
}

Here, T is a type placeholder, representing any type that will be provided when the function is called. You can use any placeholder name you wish, but T is commonly used to represent a "type" generic.

Generic Functions

The example you saw above is a generic function. Shall we see another example?

Consider the following problem: you need to create a function that will create and return an array containing a certain value repeated a specific number of times. This can be useful in various situations, such as initializing an array with a default value or generating test data with repeated values.

This value can be any type. Here's an example of how you can create this function using a generic type:

func makeArray<T>(repeating item: T, numberOfTimes: Int) -> [T] {
    var result: [T] = []

    for i in 0..<numberOfTimes {
        result.append(item)
    }

    return result
}

print(makeArray(repeating: 3, numberOfTimes: 4)) // [3, 3, 3, 3]
print(makeArray(repeating: "Hello", numberOfTimes: 3)) // ["Hello", "Hello", "Hello"]

What's happening here? I'm creating a generic function that takes a generic type called T and returns an array of type T. Inside this function, I create an array of type T, initially empty, and fill it with the item that was received as a parameter. Simple, right?

Generic Classes and Structs

Swift also allows defining generic classes, structs, and even enums. See an example below of a generic class that implements a stack:

class Stack<T> {
    public var items = [T]()

    func push(_ item: T) {
        self.items.append(item)
    }

    func pop() -> T? {
        return self.items.popLast()
    }
}

let stack = Stack<Int>()
stack.push(3)
stack.push(10)
stack.push(12)
stack.pop()
print(stack.items) // [3, 10]

Notice the instance of this class Stack, realized by the constant stack. We cannot simply instantiate with a Stack() as we would with a normal class; we need to define the type T, hence we use Stack<Int>(). If we opted for the type String instead of Int, we would do Stack<String>().

The implementation with

struct would be the same way.

Type Constraints

Swift allows you to specify type constraints on generic definitions, which restricts the types that can be used with a generic type or function. See the example below:

func findIndex<T: Equatable>(from valueToBeFound: T, in array: [T]) -> Int? {
    for (index, value) in array.enumerated() {
        if value == valueToBeFound {
            return index
        }
    }
    return nil
}

if let index = findIndex(from: 3, in: [1, 2, 3, 4]) {
    print(index) // 2
}

In the code above, T: Equatable ensures that T implements the Equatable protocol, allowing the values to be compared using ==.

If you did not include the type constraint T: Equatable in the definition of the function findIndex, the Swift compiler would generate an error because it would not be able to guarantee that the types passed to the function support the equality operator (==). Swift is a strongly typed language and requires that the operations performed on types are known and safe at compile time.

Therefore, without the constraint T: Equatable, Swift has no way of knowing if T can be compared with ==. The Equatable protocol declares the equality operator ==, meaning that any type that conforms to Equatable can be compared for equality. Without this conformity, there's no guarantee that T supports this operation.

Let's see another example below:

func encode<T: Encodable>(_ item: T) {
    JSONEncoder().encode(item)
}

In the example, the function encode is a generic function that accepts any type T as its parameter, with the condition that T must conform to the Encodable protocol.

Remember, the Encodable protocol is part of Swift's encoding and decoding data library, known as Codable.

To ensure that the function JSONEncoder().encode(item) works, our parameter item needs to be a type that conforms to the Encodable protocol. For this reason, the function has a type constraint, to ensure that this function works as expected and does not cause a compilation error.

The Relationship Between Optionals and Generics

Did you know that optionals are actually a generic enum? That's right! The definition of Optional is something similar to:

enum Optional<Wrapped> { 
    case none 
    case some(Wrapped) 
}

This means that when you declare a variable as Int?, it's shorthand for Optional<Int>.

var optionalInt: Int? = 42
// Is equivalent to:
var anotherOptionalInt: Optional<Int> = .some(42)

switch anotherOptionalInt {
case .none:  
    print("nil")
case .some(let value):  
    print(value) // 42
}

Conclusion

Generics are fundamental in Swift, allowing you to write cleaner, more flexible, and reusable code. They help us avoid duplication and maintain type safety. By learning and applying generics, you can take full advantage of Swift's powerful type features. Generics, therefore, are not just a tool for creating efficient code, but also a bridge to deeply understanding how Swift operates with types and values.

Thank you so much for reading this far.

Clean Code: Lições essenciais do terceiro capítulo

Giovanna Moeller — Thu, 14 Dec 2023 19:01:10 +0000

O capítulo 03 do livro “Código limpo” fala sobre como escrever boas funções. A principal questão é: como fazer uma função transmitir o seu propósito?

1. As funções devem ser pequenas

As funções devem ser pequenas. E elas devem ser menores do que você provavelmente está imaginando.

O livro diz que uma função deve ter no máximo 20 linhas, e que uma linha de código — independentemente do que seja — deve ter no máximo 150 caracteres.

As funções devem ter os seus objetivos declarados de forma transparente. Devem contar a sua história e devem te levar a próxima ordem/instrução.

2. Máximo de 2 níveis de indentação

As funções não devem ter muitas estruturas aninhadas. Ou seja, if dentro de if, muitas condicionais, etc. O nível de indentação de uma função deve ser de no máximo 1 ou 2. Isso facilita a leitura e compreensão.

Além disso, blocos dentro de instruções como if, else, while, devem ter apenas 1 linha, possivelmente uma chamada para outra função.

If…
    if…
    else if…
else...
    if…
    else if…
    else..
        if…

Evite isso!

3. Faça apenas uma coisa

Eu julgo este o princípio mais importante. As funções devem fazer apenas uma única coisa. Devem fazê-la bem. Devem fazer apenas ela. É o princípio da responsabilidade única.

4. Mantenha um nível de abstração

A chave para entender se uma função está realmente fazendo "uma única coisa" está em olhar para o nível de abstração.

Quando dizemos que uma função deve fazer "uma coisa", estamos nos referindo a manter todas as suas ações dentro do mesmo nível de abstração. Isso significa que todos os passos ou operações dentro da função devem contribuir diretamente para realizar o propósito geral da função, como indicado pelo seu nome.

Você pode estar se perguntando: o que significa níveis de abstração?

Um "nível de abstração" refere-se à camada ou nível de detalhamento e complexidade de um código ou de uma parte do código.

Alto nível de abstração: Isso é como olhar de um avião. Você vê a cidade, mas não as ruas individuais. Em termos de programação, é quando você lida com conceitos amplos e gerais, sem se preocupar com os detalhes específicos de implementação. Por exemplo, uma função chamada processarPagamento() pode ser uma operação de alto nível, pois você não precisa saber imediatamente como o pagamento é processado, apenas que ele será processado.
Baixo Nível de Abstração: Isso é como estar na rua, vendo cada detalhe ao seu redor. Em programação, isso envolve lidar com os detalhes específicos e complexidades de uma tarefa. Continuando o exemplo anterior, em um nível mais baixo, processarPagamento() pode envolver validar os detalhes do cartão, comunicar-se com o banco, verificar o saldo, etc.

Misturar níveis de abstração pode gerar confusão.

5. Leia o código de cima para baixo: Regra decrescente

A regra decrescente diz que a leitura do código deve ocorrer de cima para baixo, como uma narrativa, uma série de parágrafos.

6. Use nomes descritivos

Você sabe que está criando um código limpo quando cada rotina que você lê é como você esperava.

Metade do esforço para satisfazer esse princípio é escolher bons nomes para funções pequenas que fazem apenas uma coisa.

Quando menor e mais centralizada for sua função, mais fácil será pensar em um nome pra ela. E não tenha medo de criar nomes extensos.

Um nome longo e descritivo é melhor do que um comentário extenso e descritivo.

Seja consistente nos nomes. Use as mesmas frases, substantivos e verbos.

7. Parâmetros de funções

A quantidade de parâmetros ideal para uma função é zero. Caso não consiga ser zero, deve ser um. Caso não consiga ser um, deve ser dois. Sempre que possível, evite três (ou mais) parâmetros. A utilização de muitos parâmetros complica a interpretação do código.

Parâmetros são difíceis de lidar em caso de teste também. Imagine a dificuldade em escrever um teste para uma função que requer três parâmetros. Precisamos escrever todos os casos de teste para certificar que todas as combinações de parâmetros funcionem adequadamente.

Além disso, não use parâmetros lógicos, ou seja, valores booleanos. Esse tipo de parâmetro complica a função, mostrando que ela faz mais de uma coisa. Ela faz uma coisa se for verdadeiro, e outra se for falso. Separe em duas funções.

Funções que recebem um único parâmetro são chamadas de mônades. Dois parâmetros, díades. Três parâmetros, tríades.

8. Objetos como parâmetros

Quando uma função precisar de mais de dois ou três parâmetros, considere criar uma classe específica para eles. Exemplo:

func createPerson(name: String, age: String, job: String)
func createPerson(person: Person)

9. Verbos e palavras-chave

Escolher bons nomes para uma função pode contribuir muito para explicar a intenção da função e a ordem e intenção dos argumentos. A função e o argumento devem formar um par verbo/substantivo. Por exemplo: write(name) é bastante claro. Um nome será escrito. Um nome ainda melhor seria writeField(name), que nos diz que nome é um campo.

10. Evite efeitos colaterais

Evitar efeitos colaterais significa garantir que uma função ou método não altere nenhum estado fora de seu escopo ou cause mudanças inesperadas no sistema na qual não estão propostas a fazer dentro do escopo da função.

11. Separação comando-consulta

As funções devem fazer ou responder algo, mas não ambos. Sua função ou altera o estado de um objeto ou retorna informações sobre ele. Efetuar as duas tarefas normalmente gera confusão.

12. Prefira exceções a retorno de códigos de erro

Em vez de usar códigos de erro para sinalizar problemas ou falhas em uma função, você deve utilizar mecanismos de exceção. Assim, você obtém clareza do código, separação da lógica de erro da lógica de negócios e a prevenção de erros passando despercebidos.

Além disso, extraia blocos try/catch, pois eles já são um código extenso e devem possuir sua própria função, uma função exclusiva para tratamento de erro/sucesso. Uma função que trata erros não deve fazer mais nada.

13. Evite repetição (DRY)

DRY significa don’t repeat yourself, que basicamente diz para evitar duplicidade de código.

A duplicação é um problema porque ela incha o código e exigirá uma modificação dupla caso o algoritmo precise mudar. Também representa uma oportunidade dupla para um erro de omissão.

Conclusão

Programadores experientes veem os sistemas como histórias a serem contadas em vez de programas a serem escritos.

Se seguir as regras descritas neste resumo, você terá funções mais curtas, bem nomeadas e organizadas. Lembre-se que seu objetivo verdadeiro é contar uma história.

Clean Code: Lições essenciais do segundo capítulo

Giovanna Moeller — Thu, 16 Nov 2023 21:01:36 +0000

O capítulo 02 do livro "Código limpo" fala sobre nomeação.

Mas nomeação de que, exatamente? Bom, quando falamos em software, temos nomes em vários lugares: variáveis, funções, classes, parâmetros, módulos, arquivos-fonte, diretórios, etc.

Portanto, vamos falar sobre criar bons nomes:

1. Use nomes que revelem o seu propósito

O nome de uma variável, função, classe, etc, deve dizer o porquê aquilo existe, o que ele faz e como é utilizado. Se um nome requer um comentário, então ele não revela seu propósito.

Exemplo:

Int d; // tempo decorrido em dias

Isso não significa absolutamente nada. Nem mesmo o comentário está bom o bastante para entendermos. Tempo de quê estamos falando com esta variável?

Um exemplo, seria nomear como daysSinceFileCreation, que significaria o tempo de dias que se passaram desde que um arquivo foi criado, por exemplo. Muito melhor, não?

Mesmo um código simples pode não ter um propósito, ou pelo menos você não consegue identificar este propósito porque as variáveis não estão definidas de forma com que mostrem pra que servem, o que fazem, por que existem, etc.

Quando falo de variáveis, quero dizer qualquer coisa que pode ser nomeada.

O ponto é: escolha nomes que não fique difícil entender o que está acontecendo. Seja extremamente explícito e não importa se o nome ficar muito grande, precisa ser descritivo.

Uma diferença entre um programador esperto e um programador profissional é que este entende que clareza é fundamental. Os profissionais escrevem códigos que outros possam entender.

2. Evite informações erradas

Se você criar uma variável chamada de accountsList, mas se o que armazena as contas não for uma List de verdade, é uma informação errada e pode confundir.

Outro ponto: não utilize nomes muito parecidos, como ControllerForEfficientHandlingOfStrings e ControllerForEfficientStorageOfStrings. São muito semelhantes e passíveis de confusões.

3. Faça distinções significativas

Como você diferencia uma função chamada de getAccount para getAccountInfo? Muito difícil, não? E como você diferencia uma classe chamada de ProductData e ProductInfo? Imagine que você acabou de chegar no projeto. Como você deve saber qual utilizar? Complicado, certo?

Isso normalmente acontece pois não é possível usar o mesmo nome para referir-se a duas coisas diferentes num mesmo escopo, então há a alteração de forma meio "arbitrária", sem pensar. Não faça isso! Faça distinção dos nomes de uma forma que o leitor compreenda as diferenças.

4. Use nomes pronunciáveis

Imagine criar uma variável mdy para representar mês, dia e ano? Ou pior, uma variável chamada gdymdym que representa "generate date, year, month, day, hour, minute"? Como isso seria pronunciável? Impossível, certo? Além de que não é nem um pouco descritível.

5. Use nomes passíveis de busca

Imagine que você declare uma variável s que realiza a soma dos salários de membros de uma equipe. Quando você for buscar pela variável s, no seu código, irá se deparar com várias outras palavras que contém a letra s.

Você deve preferir nomes com uma única letra apenas se forem usados como variáveis locais dentro de métodos pequenos, como por exemplo i para referir ao index de um elemento de um array dentro de um loop.

O tamanho de um nome deve ser proporcional ao tamanho do escopo.

6. Nomes de classes

Classes e objetos devem ter nomes com substantivo(s), como Customer, Account, AddressParser, etc. Não deve ser um verbo e não deve ser genérico, como Parser, Data, Info, etc.

7. Nomes de métodos

Nomes de métodos devem possuir verbos indicando a ação realizada pelo método, como deletePage, savePage, getBalanceFromAccount, etc.

Use e abuse de prefixos, como get, para recuperar um valor, set para definir ou atualizar um valor, is para métodos que verificam uma condição, retornando um booleano, etc.

8. Utilize uma palavra por conceito

É essencial manter a clareza na nomenclatura. Considere, por exemplo, que em um projeto existem dois componentes distintos: um chamado UserController e outro nomeado como TransactionManager. Isso pode gerar confusão, especialmente para quem é novo na equipe.

Afinal de contas, qual a real diferença entre um 'Controller' e um 'Manager'? Ambos não desempenham funções semelhantes no projeto? Essa ambiguidade de nomes pode levar a mal-entendidos desnecessários. Alguém pode até pensar que 'Controller' e 'Manager' representam conceitos de programação distintos e perder tempo procurando explicações para essa suposta diferença.

Para evitar essa confusão, é necessário adotar uma abordagem consistente na escolha de nomes. Se um componente é denominado como 'Controller', então outros componentes com funções semelhantes devem seguir essa nomenclatura.

9. Adicione um contexto significativo

Quando você tem um conjunto de variáveis como firstName, lastName, street, number, city, state e zipcode, juntas elas claramente representam um endereço. No entanto, a situação muda quando você encontra uma dessas variáveis, como state, ou number, isoladamente em um método. Não é imediatamente óbvio que state faz parte de um endereço.

Uma forma de resolver isso é usar prefixos para dar contexto às variáveis. Por exemplo, addressFirstName, addressLastName e assim por diante. Esses prefixos ajudam a indicar que estas variáveis são partes de uma estrutura maior, no caso, um endereço.

Entretanto, uma abordagem mais eficaz seria criar uma classe chamada Address. Com essa classe, até o compilador reconheceria que estas variáveis pertencem a um contexto maior. Isso não só ajuda na organização do código, mas também melhora a legibilidade e a manutenção, pois torna explícito que essas variáveis estão agrupadas sob um conceito comum.

Conclusão

Para mim, o que mais tirei proveito desse capítulo foi: utilizar de nomes claros e descritivos que revelem o propósito/intenção do seu código.

Entretanto, refatorar para nomes significativos é um processo que não é fácil. Às vezes, você escolhe um nome e pensa "está bom", e então amanhã, você consegue pensar em um outro nome melhor ainda. É um processo que leva tempo. E sempre há código a ser refatorado.

Como você pode melhorar seu código hoje?

Clean Code: Lições essenciais do primeiro capítulo

Giovanna Moeller — Thu, 09 Nov 2023 17:56:10 +0000

O primeiro capítulo do livro começa com uma história sobre um aplicativo popular nas décadas passadas que declinou devido ao código confuso e não gerenciável, demorando muito tempo para lançar novas atualizações, corrigir bugs, etc. Isso serve como uma introdução ao problema central abordado no livro: os efeitos prejudiciais de um código ruim.

Mas, afinal de contas, por que criamos códigos ruins? Foram criados sob pressão? Criados rapidamente? Você queria terminar a tarefa logo e pensou “depois eu refatoro e faço melhor”? Daí vem uma frase mostrada no livro que gostei muito: Mais tarde é igual a nunca.

E quais as consequências de um código ruim? Conforme o tempo passa, a produtividade diminui. Uma equipe começa a perceber que o código que criaram rapidamente há alguns anos está dando prejuízo nos dias de hoje: cada alteração feita no código causa uma falha em outras partes do mesmo código, cada adição ao código faz com que códigos já existentes devem ser modificados, entre outros diversos problemas. A bagunça está feita.

Dedicar tempo para escrever código limpo não é apenas eficaz em termos de custo, mas uma questão de sobrevivência profissional.

Tentamos nunca nos responsabilizar por ter criado um código ruim, sempre colocando a culpa em curtos prazos, pressões, clientes intolerantes, etc. Mas lembre-se: você é um profissional, e não é profissional que programadores cedam à vontade dos gerentes que não entendem os riscos de se gerar códigos confusos.

Saber distinguir um código limpo de um código ruim não significa que você sabe escrever um código limpo. Escrever código limpo exige o uso disciplinado de diferentes técnicas. Essas técnicas estão relacionadas a como organizar e estruturar o código para que ele seja fácil de entender e manter. Com o tempo e a experiência, você desenvolve uma espécie de "senso" ou intuição para identificar o que torna um código mais "limpo" ou melhor.

E o que significa um código limpo? Existem várias definições, e para responder essa pergunta, Robert C. Martin perguntou a diversos programadores experientes o que eles achavam.

Bjarne Stroupstrup, criador do C++, diz que o código limpo faz bem apenas uma coisa. Ele é centralizado.

Uma metáfora expressa no livro que gostei muito foi

“Uma construção com janelas quebradas parece que ninguém cuida dela. Dessa forma, outras pessoas deixam de se preocupar com ela também. Elas permitem que as outras janelas es quebrem também. No final das contas, as próprias pessoas as quebram. Elas estragam a fachada com pichações e deixam acumular lixo. Uma única janela inicia o processo de degradação.”

Um código ruim incita o crescimento do caos num código. Quando outras pessoas alteram um código ruim, elas tendem a piorá-lo.

Grady Booch, autor de um livro sobre orientação a objetos, diz que um código limpo é simples e direto, estando repleto de abstrações claras e linhas de controle objetivas. Deve ser decisivo, sem especulações. Deve expor claramente as questões do problema a ser solucionado.

Dave Thomas, fundador da OTI, diz que um código sem testes não está limpo. Ressalta também que o código deve ser escrito de uma forma que seja inteligível (compreensível) aos seres humanos.

Michael Feathers, autor de um livro sobre códigos legados, diz que um código limpo sempre parece que foi escrito por alguém que se importava com o que estava escrevendo.

Ron Jeffries, autor de um livro C#, resume que o código limpo deve ser um código com testes, sem duplicação, entidades devem seguir o padrão de responsabilidade única (isto será abordado e discutido mais a frente), deve ser expressivo e com pequenas abstrações.

Ward Cunningham, cocriador do eXtreme programming, diz que ao ler um código limpo nada deve te surpreender. O código é óbvio, simples e convincente. Cada módulo prepara o terreno para o seguinte.

Por fim, o livro diz para não tornar este conhecimento descrito ao decorrer como “a única fonte da verdade”, você pode concordar ou discordar de certos pontos. E está tudo bem. Além disso, somos autores de códigos e todo autor tem leitores, com os quais uma boa comunicação é responsabilidade dos autores. Constantemente também lemos códigos antigos quando escrevemos novos.

Se quer que seu código seja de fácil escrita, torne-o de fácil leitura.

Não basta escrever um código bom. Ele precisa ser mantido sempre limpo. “Deixe a área do acampamento mais limpa do que como você a encontrou.”

A refatoração para o código limpo nunca acaba. Sempre há código que pode ser melhorado.