Código Limpo: Começando a praticar

Você provavelmente já ouviu “bom código dispensa comentários” ou achou muito difícil praticar código limpo, certo?

Neste post, vou contar toda a verdade sobre as partes reais do código limpo!

Se você pousou aqui de paraquedas, seja bem-vindo!

Primeiro, dê uma olhada no que já discutimos sobre código limpo.

Comece com código limpo

E então, em tudo isso, alguém deve ter lhe dito que se você nomear bem as coisas, por exemplo, seja uma variável, uma função ou uma classe, você não precisa escrever um comentário.

Finalmente, talvez você tenha tentado impulsivamente absorver todo esse material de código limpo para si mesmo.

Claro, eu cometi o mesmo erro quando ouvi pela primeira vez sobre isso:

Pensar em código limpo é dar nomes grandes e descritivos às coisas em seu código sem se preocupar em ser feliz.

Lamento informá-lo, mas este não é o caso.

Nomes são importantes

Para começar, acho muito claro que os nomes importam!

Tive um professor que me ensinou a importância dos nomes de duas maneiras muito interessantes:

Quando um aluno se apresenta apenas pelo primeiro nome, ele nunca aceita. Nome e sobrenome são sempre obrigatórios;
Certa vez, um aluno argumentou que certa configuração era “apenas um nome” e ouviu o professor dar tantas palestras sobre como ele não queria ser chamado de outra coisa além de seu nome, que certamente nunca o esqueceu.

Bem, eu estou lá, eu sou um estudante. xD

O problema com os nomes é que nunca aprendemos nenhuma técnica de nomenclatura.

Isso geralmente é bastante subjetivo, e nós, humanos, somos muito bons nisso, no entanto.

As pessoas vivem por nomes. Mas nem sempre um nome pode conter todas as informações que você deseja transmitir sobre algo.

Se eu nomeasse meu cachorro de Monstro, eu poderia confundi-lo se eu quisesse dizer Harry Potter ou Kleber BamBam.

Mas, na verdade, dei esse nome a ele porque ele me assustou ao aparecer na minha casa à noite enquanto eu dormia.

Convenhamos: seja qual for o motivo, é um bom nome.

Habilidades práticas de código limpo

Então, como discutimos no último artigo, sempre que encontramos a subjetividade necessária para praticar código limpo, e em nosso trabalho, tentamos criar padrões.

Padrões

Já que não podemos carregar tanta informação em um nome, vamos normalizar nossas expectativas mínimas para um nome.

Programação requer boas práticas, PHP, Java, JavaScript são boas, mas como ter boas práticas ao escrever código?

Neste artigo, vamos nos concentrar nas noções básicas de boas práticas de principalmente nomenclatura de variáveis ​​e funções de suporte (ou seja, funções que não são métodos).

Quem sabe não podemos discutir cada um deles especificamente em artigos futuros, incluindo classes, interfaces, métodos e tudo mais!

Nome significativo

Primeira dica infalível: nunca reutilize exatamente o mesmo nome em outro contexto sob nenhuma circunstância.

Se você não tiver certeza se a variável ainda está sendo reutilizada no mesmo contexto, não a reutilize.

Confie em mim, você não quer ter dois cachorros chamados Monster, na verdade eu já estou começando a me perguntar se o nome é realmente legal.

Dar o mesmo nome a duas coisas diferentes requer alguma habilidade e cautela, especialmente ao praticar código limpo.

Obviamente, você pode chamar seus dois cachorros… bem… cachorros.

Mas usar esse nome para se referir especificamente a um ou outro pode fazer com que seu discurso perca a clareza.

Mas um bom exemplo de algo semelhante a este trabalho está no filme Bird Box, em que Sandra Bullock se refere aos meninos e meninas que a acompanham.

Nesse caso, o contexto em que o filme está inserido deixa claro a quem ela se refere, e o significado de meninos e meninas é claro.

Significado ao praticar código limpo

De acordo com o Dicionário do Google, “significado” é uma relação de identificação.

Coisas significativas são identificáveis. Portanto, um nome deve dar significado ao seu nome.

no livro de código limpo. O Agile Software Craftsmanship Handbook tem um capítulo inteiro discutindo a importância, as melhores práticas e as considerações de nomear coisas em nosso código.

Como sempre, tudo isso é muito subjetivo e Robert tentou fornecer muitos exemplos de como essa qualidade de software pode ser alcançada.

Agora falarei sobre a técnica dele com algumas outras técnicas minhas.

Aula de Sintaxe

Você acha que saber matemática é suficiente para programar bem? Encontrado errado!

O próprio tio Robert definiu quais variáveis ​​deveriam ser funções de substantivos e verbos.

Bem, essas são aulas de gramática, e para dar bons nomes, precisamos saber não só sobre elas, mas também sobre outras 8 existências.

Para ajudar você a lembrar disso, separei um artigo sobre classes de palavras da Daniela Diana, que é muito legal e conciso.

Boas práticas
Portanto, temos as seguintes práticas recomendadas:

Nunca use pronomes, artigos (olá WordPress) e interjeições.

Por exemplo:

Tente evitar números, preposições e conjunções.

Essas classes só fazem sentido em frases mais longas, o que exigiria que você as nomeasse muito longas para que elas fizessem sentido.

Além disso, geralmente isso dependerá muito do contexto da inserção, eles podem não ser necessários, pois sua localização informará o que o nome significa.

Consultar exemplo:

Siglas

A gente de computação adora falar orientado a siglas, né?

É SaaS, IaaS, DRY, MVC, DDD, JSON, CSS, JS, BI, IOT, POC, TDD, CMS, DBMS, SOLID, OOP, CRM, DNS, ERP, FTP e ainda tem mais…

HTTP, SSL, TCP/IP, SSH, DB, LAN, WAN, HTML, XML, SQL, GNU, PHP, UI, UX, URL, VPN, VM, ASCII, BIOS, DDoS, SSD, ETL, MAC, etc.

Ufa!

Inclua fortes críticas a si mesmo:

Essas siglas muitas vezes complicam e refinam a fala quando, na realidade, significam coisas extremamente simples.

Acho bem legal e democrático evitar siglas sempre que estamos falando de tecnologia, principalmente sem antes apresentá-las a todos.

Na verdade, estamos tão acostumados com isso que todos fazemos isso quando nomeamos as coisas em nosso código.

Esta é uma prática antiga.

A partir do momento em que o algoritmo é escrito, deve-se tomar cuidado com o tamanho final do arquivo para que ele caiba em dispositivos de armazenamento removíveis como disquetes (!!) e cartões perfurados (!!!).

Esta é a menor das nossas preocupações agora, então não use siglas e abreviações ao praticar código limpo!

Evite nomes muito parecidos
Considere a diferença claramente!

Tente preencher uma chave para cada item do array no código abaixo:

O nome de cada função isoladamente não está ruim.

Mas veja como é difícil identificar e como é fácil ficar confuso sobre quais postagens e quais comentários.

Isso é comum no código de trabalho do dia-a-dia, especialmente quando não há uma política de revisão de código antes da entrega.

Para evitar o mesmo problema, é melhor descartar prefixos e sufixos em nossos nomes.

Se você precisar classificar isso, talvez seja o caso de usar outra estrutura externamente que faça sentido para eles.

Consistentemente

Existem várias palavras-chave que significam a mesma coisa.

Por exemplo, as palavras pesquisar e localizar podem ser usadas para fornecer o mesmo significado de pesquisa.

Nesses casos, a coerência do código é uma coisa boa.

Na produção de texto, a coerência evita que seu texto perca o significado da mensagem.

Os termos que foram incorporados por referência são então repetidos com significados adicionais ao longo do texto quando reaparecem.

Na programação, temos que fazer o mesmo.

É por isso que devemos escolher uma estratégia de normalização:

Se estivéssemos decidindo quais funções de pesquisa usar para pesquisar registros no banco de dados, não teríamos criado uma função searchById para a mesma finalidade.

Essa parte foi divertida!

No livro Clean Code, Robert não deixou de mencionar que podemos usar funções com os nomes find e search desde que forneçam significados diferentes (ou seja, funções).

Assim, podemos dizer que uma função com find em seu nome implica uma pesquisa no banco de dados.

Enquanto a pesquisa com busca dentro da estrutura de dados específica do nosso aplicativo.

Quando você praticar código limpo, observe novamente a importância da padronização da equipe.

Tipos de idioma e caso ao praticar código limpo

É meio clichê, mas é realmente necessário: programar em inglês.

Se você não domina o idioma, aproveite para praticar.

É o ambiente perfeito para você cometer erros sem se sentir envergonhado, pois mesmo quem é proficiente no idioma pode escrever nomes ruins.

O pior caso é manter o código em “português”.

É muito difícil escrever tudo em português porque às vezes você precisa de algo nativo da linguagem de programação que está usando e, inevitavelmente, do inglês.

Ainda assim, é importante entender como está o conhecimento da língua neste artigo, até por conta das regras do português.

Finalmente, quero prestar atenção aos tipos de caso. Eu não posso traduzi-los, então os termos têm que estar em inglês de qualquer maneira:

Camel Case: Comum em funções nomeadas. Eu também gosto de usar este caso para variáveis ​​que armazenam objetos. Formato:


Pascal Case: é assim que nomeamos classes, não é legal utilizar este case em nenhum outro caso. Formato: PascalCase. Ex: class


Snake Case: comum para nomes em geral e vem em dois sabores:
Upper Snake Case: comumente utilizada para nome de constantes. Formato:


Lower Snake Case: utilizada nas mais diversas coisas. Eu gosto de usar em nomes de arquivos, variáveis com valores simples (não objetos) e ids em tags HTML.
No PHP as funções nativas estão quase todas neste case type. Formato:

 

Espero que tenham gostado! Até a próxima!