Voltei com a continuação do resumo do livro do Tio Beto. Desta vez, serei menos reaça e vou assumir que vocês leram mais do que o meu resumo anterior.
No segundo capítulo desta incrível obra, temos o tio Beto tratando do problema que pra mim é a raiz de todo o mal do mundo Dar nomes aos bois seja a variáveis de ambiente, classes, métodos ou até o projeto. Dar nome para as coisas é importante. As minhas ex que o digam...
O Tio Beto nos traz a problemática de que algo que não possui nome é algo que não possui identidade e logo não dá pra saber o que se faz com aquilo. A primeira dica que ele dá é evitar não nomear componentes. Por mais simplório que seja, ele merece um nome. Imagina no cara que parou e pensou em nomear o nome do menor osso do corpo humano como estribo? não dá nem pra quebrar essa porcaria! Evite dar nomes como a, x , i , alpha centauro omega3 topterm. Isto nada quer dizer e no final te come um tempo danado de raciocínio. Por exemplo:
final x = a();
for(i = 0; i < x.length ; i++){
print(x[i].b())
}
Sintaxicamente, se você tem alguma experiência com uma linguagem de programação, sabe o que teoricamente as funções a e b realizam. Porém, até para pessoas experientes, esse código é um tanto seboso. Não se engane, esse tipo de coisa ocorre muito.
A segunda dica de como se nomear coisas em programação que o tio Beto na verdade é uma regrinha. O nome da coisa deve responde a uma das seguintes perguntas:
- por que existe?
- o que faz?
- como é utilizado? Vamos voltar a aquele código seboso e reescrever aquele trecho levando em consideração que não fui eu que o fiz... ops, que foi bem escrito.
final accounts = getAccounts();
for(index = 0; index < accounts.length; index++){
print(accounts[index].getNameAccount())
}
Arrisco a dizer que ele ficou até mais elegante não é mesmo? Um código pomposo, feito com esmero. Mostrando que você tomou café e vergonha na cara de manhã cedo. Porém, este código ainda não está 100% como o tio Beto pede. As variáveis accounts e index respondem as perguntas acima? Não. Mas como já concordamos aqui, o tio Beto é um chato e nem sempre vamos seguir 100% o que ele diz, mas vamos adaptar. Mais do que responder as perguntas, você consegue me responder o que aquela variável é?
Passado o momento filosófico onde se rebelamos contra o tio Beto, levantamos foices e martelos e queimamos os meios de pro... foi um ensaio, calma! Passado esse primeiro momento que vemos que nomes são sim importantes e que precisamos nomear aqueles lances. O tio Beto nos pontua outra parada. Evite dar informações erradas, nomeie as coisas como elas são. Nada de declarar um cpf como inteiro? não. Isso você pode fazer, é estúpido, mas pode fazer. O que o tio Beto explica é que devemos ao máximo evitar nomenclaturas que levem a tipos de objetos diferente, a funções que nada tem haver com aquilo que o nome o leva a crer que executam, classe que não possuem o grupo de informações corretas. Exemplo?
class IncrementPomodoro{
static Future<bool> loginAccount(Object o){
return Pomodoro.newCicle(o);
}
}
O que tem haver o fundo com as calças no exemplo? Exatamente. Mas o retorno pode ser o esperado de um login, mas vem de uma classe que no nome Incrementa um pomodoro, mas no corpo da função ele tá abrindo um novo ciclo. São tantas perguntas não é mesmo? Então, o tio Beto só avisa que você não seja tonto de fazer esse tipo de coisa.
Falando em tonto, o tio Beto também pensou no outro tipo de desenvolvedor. Ah e como ele pensou. O desenvolvedor pica das galáxias, aquele desenvolvedor top master ultra blaster atualizado na versão 3.10.2+1. O cara que nesse momento tá esfolando o dedo no controle de Xbox jogando o novo joguinho espacial. Esse cara ai recebeu atenção do Tio Beto e uma recomendação. Não seja espertinho no código. Não coloque referências nerds, referências pops, referências históricas ou sei lá, do finado Twitter. Faça o favor ao universo. Ninguém precisa saber o que 42 significa. o que é uma toalha. O que é um sabre de luz jedi. Não traga pra dentro do código algo que não é do escopo do entendimento do projeto. Além de ser prejudicial ao entendimento da equipe, pode te gerar uma cacetada de problemas com o RH. E lembre-se, só gostamos do RH para nos contratar e nos promover.
Nomear coisas é realmente um trabalho chatinho às vezes e nem sempre dar certo de primeira. Se você estar começando agora na área de programação, eu indico perder um tempinho procurando métodos de renomear arquivos, classes, funções e variáveis dinamicamente na sua IDE. Te salva um tempão e te ajuda a melhorar a qualidade no seu código, o que é muito avaliado inicialmente. Nomes é uma coisinha tão simples de se fazer em programação e que te vale muito. Não negligencie.
No mais, até o próximo capítulo. Vamos aprender o que esse velho chato acha sobre funções!
Top comments (0)