ITnerante

Estudos de TI para Concursos Públicos

Nos últimos dias tenho me dedicado a estudar sobre Clean Code que é um assunto ainda não muito abordado em concursos ainda, (a Cespe está recorrentemente cobrando) mas é uma prática já bem difundida para os desenvolvedores que a cada dia desejam aprimorar seus conhecimentos técnicos nessa vasta área de conhecimento. Essa abordagem do "Código Limpo" se baseia amplamente no livro Clean Code do Robert Martin. Nessa postagem irei abordar os aspectos principais do cap 2 (que é onde reside boa parte das questões já elaboradas de concurso)  do livro onde é explorado a importância dos nomes significativos seja na nomeação de uma variável, classe ou método. Ao final deste post traremos 2 perguntas voltadas a este assunto que versaram 2 concursos da CESPE (nos concursos TRE MT e TRE PI recentemente). 

P.S Vale ressaltar que no livro os exemplos de código são abordados na linguagem Java, o que muito não importa pois as dicas e macetes que o livro traz prescinde qualquer tecnologia ou linguagem.

   Robert começa o capítulo ressaltando a importância que a nomeação seja de variável, classe ou método tem para um código. Durante o seu capítulo, Robert coleta depoimentos de alguns nomes importantes na área da Informática. Um deles, Grady Booch, que compara a legibilidade de um código limpo com uma leitura de uma boa prosa que além de não confundir o desenvolvedor também possibilita para que o mesmo consiga abstrair as soluções que objetivam o código. Nessa dilema, Robert elenca algumas características de uma boa nomeação no código são alguma delas:

  • Usar nomes que revelem seu propósito: Um exemplo clássico e até citado no livro é evitar a declaração de uma variável genérica. Ex: int d; //para se referir a dias. É interessante ressaltar que essas variáveis genéricas (i, j = que são muito presente em matrizes ou vetores, etc) não são totalmente descartadas, desde que usadas como variáveis locais e num método ou função pequena. Essa característica também é recorrente quando a situação não permite uma nomeação mais clara de uma variável. Nesse caso Robert aponta dois pensamentos. Um pensamento voltado na perspectiva do desenvolvedor (domínio da solução) e outro na perspectiva do cliente (domínio do problema). Sendo que de acordo com ele deve ser priorizado a perspectiva do desenvolvedor ou seja, nomear algumas variáveis com palavras técnicas da área utilizado no desenvolvimento do dia - a - dia ele até cita o exemplo de uma: "AccountVisitor" (conta do visitante) além de representar uma palavra voltada para a linguagem do negócio também se torna familiar a um desenvolvedor que conhece o padrão de projeto Visitor. Nos casos em que o domínio da solução não for eficiente, pode-se usar o segundo pensamento, que tem a ver com a perspectiva do cliente. Nesse caso é nomeado uma variável técnica porém para a área do sistema afim. Pelo menos o desenvolvedor poderá se informar com o cliente quando ver uma variável nomeada na linguagem técnica do cliente quando for o caso.
  • Evitar informações dúbias: Um caso clássico deste é utilizar a letra 'l' com '1' dentro de um código ainda mais quando estiverem juntos numa mesma expressão. O autor até chega a dizer que já conheceu autores de código que tiveram de modificar a fonte do código para poder distinguir melhor essas semelhanças, gerando mais trabalho, uma vez que a simples mudança de nome de variável resolveria.
  • Usar nomes passíveis de busca: Essa característica se encaixa bem quando uma variável tem um escopo global. Imagina que temos uma variável que captura o nome do usuário a partir do momento que o mesmo faz um login. Essa variável no tempo de sua declaração foi nomeada com a letra "u". Depois de alguns módulos já construídos e com problemas já de conflitos de variáveis nas classes que utilizam essa variável, o desenvolvedor resolve ir até a classe que foi declarada o nome do usuário e para fins de eficiência ele resolve buscar na sua classe o nome da variável. O problema é que ele vai se dá conta no momento da pesquisa que a cada 2 linhas existe a presença da letra "u" no código. Aprendido a lição o desenvolvedor renomeia a sua variável para uma que possa facilitar em futuras consultas. Uma boa dica dada por Robert é que: "O tamanho de um nome de variável deve ser proporcional ao tamanho do escopo".
  • Nomes de Classes: Essa é uma das características mais simples, porém está presente na maioria das questões de concursos que versa sobre esse tema. De acordo com Robert, classes e objetos devem ter nomes com substantivos. Ex: Cliente, AnaliseEndereco.  Evita-se usar nomes de verbos para nomear classes.
  • Nomes de Métodos: Nesse caso os nomes devem ter a presença de um verbo. Ex: postarPagamento, excluirPagina.
  • Usar palavras pronunciáveis: Robert aborda aqui sobre a importância que o cérebro tem de conceituar palavras. Que por definição são pronunciáveis, neste caso segundo ele seria um desperdício não criar palavras que soem como pronunciáveis dentro de um código.

Ok. Feito esse resumo bem enxuto deste capítulo vamos as 2 questões deste post como prometido.

Q1 - TRE MT 2015 Assinale a opção que apresenta instruções de elaboração corretas de acordo com a

técnica de Clean Code

 a) Os nomes de variáveis devem ser pronunciáveis e devem ter sentido conhecidos.

 b) Os nomes de classes devem ser verbos no infinitivo e os de métodos devem ser substantivos.

 c) Os nomes de funções devem ser longos e descritivos.

 d) Os parâmetros devem ser aglutinados em funções, e cada função deve ter no máximo 3 parâmetros.

 e) O comando return deve ser evitado, ao passo que o continue e o break devem ser priorizados, assim como o goto

Q2 - TRE PI 2015 Acerca do Clean Code assinale a opção correta

 a) A segurança do código é vital, por isso os programadores devem deixar o código o mais obscuro possível.

 b) Se um valor deve ser utilizado em múltiplos locais do código, é imperativo atribuir esse valor a uma variável ou a uma constante com nome amigável.

 c) As classes devem ser possuir nome amigável oriundo de verbos, escolhidos no infinitivo, e não no gerúndio.

 d) Para customizar o código, deve-se utilizar o mesmo termo para duas diferentes ideias.

 e) O uso das variáveis devem ser simplificadas, de forma a não criar códigos gordos - por exemplo, o uso de x para o nome de uma variável é mais apropriado que MediadosAlunosAprovados.

Vamos à resolução:

Q1:

 a - Essa assertiva traz duas das características citadas acima, o uso de palavras pronunciáveis e palavras que tenham um propósito, portanto, questão CORRETA.

 b - Essa assertiva retrata sobre a nomeação de classes como falamos acima a regra é clara e simples, e muito cobrada em provas, classes devem ter nomes com substantivos e não verbos, portanto questão ERRADA.

 c - Essa assertiva versa sobre funções que é um tema que versaremos no próximo post (inclusive com uma questão garantida). Por isso vamos simplesmente apontarmos a questão como ERRADA e explicarmos no próximo post.

 d -Vamos estudar sobre esses detalhes num post mais à frente mas convém sabermos que uma função não delimita o número de parâmetros, portanto questão ERRADA.

 e - Eu diria que essa alternativa poderia ser resolvida sem conceito algum de Clean Code. Primeiro ela afirma que é recomendável se usar break e continue ao invés de return, o que já torna a assertiva errada pois ambas palavras não tem caráter excludente tendo cada uma, uma função totalmente de outra. A questão piora ainda mais quando se refere ao goto que é uma prática de desvio incondicional que já foi comumente usada mas hoje não é recomendada.

Q2:

 a - A assertiva começa bem tratando sobre a importância da segurança do código, entretanto não é tornando-o obscuro que vamos atingir esse objetivo, portanto questão ERRADA.

 b - A assertiva chega a soar um pouco forte com aquela palavra "imperativa", entretanto não compromete esta questão. Lembra daquela dica do Robert? "O tamanho de uma variável é proporcional ao tamanho do seu escopo" a questão traz a hipótese de que determinada variável é muito utilizada em diferentes partes do código, por isso é extremamente importante que a mesma tenha um nome amigável, seja para que possa facilitar numa futura busca, ou quando o desenvolvedor ver ela no código e associar ao domínio de solução ou domínio do problema, portanto questão CORRETA.

 c -Olha só, caindo novamente. Só em dizer que classes se originam de verbos já temos o erro, portanto questão ERRADA.

 d - Essa assertiva vai de encontra à característica que prega sobre evitar informações dúbias, portanto questão ERRADA.

 e - Essa assertiva propõe a substituição de uma variável que está nomeada seguindo características do Clean Code, pois nitidamente o nome revela um propósito bem definido, por uma variável bem genérica, portanto questão ERRADA. Só um ressalva de que variáveis como "x", "j", "i" não recusadas no Clean Code, desde que estejam inseridas num bloco de código pequeno, e que acima de tudo tenham um escopo local.

Com isso galera fechamos nossa primeira parte deste vasto assunto que as bancas de concursos estão começando a olhar com outros olhos, inicialmente a CESPE, mas acredito que logo as outras estarão abarcando este conteúdo nos editais. Pra quem quiser dar uma conferida no livro esse mini resumo foi totalmente embasado no capítulo 2 do livro. Se a galera tiver experiência no assunto, vamos usar os comentários para discutir sobre esse tipo de assunto. Caso tenha falado algum absurdo, ou alguma crítica a ser feita pode ser informada nos comentários, como falei é um tema que estou estudando e que pela ausência de material desse assunto aqui no fórum resolvi gravar esse post com vista que seja útil pra pessoas que tenham interesse nessa área.

Exibições: 1321

Comentar

Você precisa ser um membro de ITnerante para adicionar comentários!

Entrar em ITnerante

Comentário de Cássia dos Santos Freitas em 6 setembro 2017 às 15:43

Muito bom e obrigada por compartilhar o material! :)

Comentário de Rodrigo Macedo em 10 março 2016 às 10:49

@Jan que bom que gostou ;)

Comentário de Jan Sousa em 10 março 2016 às 10:31

Gostei!

Comentário de Rodrigo Macedo em 8 março 2016 às 11:26

@Douglas vlw cara .. 
@Felipe vlw amigo obrigadão pelo elogio. 

Comentário de Felipe Travassos Rodrigues em 8 março 2016 às 9:28

Parabens meu amigo, muito boa sua didática com clean code!

Comentário de Douglas Gomes em 8 março 2016 às 8:27

Muito bom mesmo! Parabéns!!!

Comentário de Rodrigo Macedo em 8 março 2016 às 8:25
@Camila e @Milton que bom que gostaram.
Comentário de Camila Pontes em 8 março 2016 às 0:34

Muito bom!

Comentário de Milton Junior em 26 fevereiro 2016 às 10:55

Muito bom! Obrigado por compartilhar.

Comentário de Rodrigo Macedo em 23 fevereiro 2016 às 21:10

Vlw mano

Badge

Carregando...

© 2017   Criado por Walter Cunha.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço