Já fui elogiado por escrever um código todo “indentadinho”, ter umas variáveis bem claras e até por comentar o que faço! Quem não gosta de encontrar um código otimizado, fácil de entender, fácil de manter e que pode ser expandido com facilidade?
As regras estão aí para serem seguidas e tornar a convivência no escritório mais tranquila. As únicas “brigas” deveriam acontecer para descobrir quem esvaziou a cafeteira e não fez mais café.
Mas…
Existem aqueles dias que o tempo é curto, não dá para fazer tudo como manda o manual, uma gambiarra resolve, o código compila assim mesmo, o cliente fica satisfeito e partimos para o próximo projeto. Para esses casos, não tem jeito: são aqueles maus-hábitos em programação que deveríamos largar. Mas não largamos.
Nunca confie em um computador que você não possa jogar pela janela.
Documentação, por exemplo. Vamos ser francos: ninguém gosta de fazer. Mas todo mundo gosta quando encontra uma. Ou quase. Em um cenário ideal, todos os programadores iriam criando a documentação no mesmo ritmo em que vão produzindo (e não no final, quando já se está exausto e com prazo apertado). E atualizando a documentação sempre que há uma mudança. Mas o que acontece? Uma documentação (quando existe), criada às pressas ou que não reflete mais as características do projeto e só confunde. Na dúvida, use sempre nomes de funções e variáveis que façam sentido óbvio e espalhe uns comentários aqui e ali. “Espera aí, o Código Fonte está me sugerindo pular a documentação?”. Não, você não leu isso aqui. Circulando…
Desde que inventaram o GOTO, mais ou menos no Período Paleolítico, o recurso vem sendo usado e, principalmente abusado, na programação. Quem não sabe usar, acaba fazendo um labirinto que um herói grego conseguiria encontrar a saída. É prático, é cômodo, é rápido para quem faz, mas quem chega depois (ou mesmo quem fez, meses depois) precisa desenrolar esse novelo para achar onde está um problema ou onde é possível acrescentar uma funcionalidade ou melhorar a performance. O GOTO não morreu com a linguagem em que nasceu. Ele continua entre nós, na forma de um BREAK aqui, um RETURN ali. Se combinar esse ninho de cobras com a falta de documentação, então é receita de desastre.
Mas isso não significa que você não possa ceder à tentação e, na pressa, usar o esquema do GOTO para escapar de um caminho. Só não vá usar um GOTO para escapar do GOTO para ir para outro GOTO, senão… tem gente boa que foi mesmo e nunca mais encontrou o caminho de volta.
Existem duas formas de se escrever programas livres de erros; apenas a terceira funciona.
Quer algo mais irritante que um programador que não declara tipos? É gente que aperta o botão do elevador para subir e para descer. Muito mais irritante. Até houve um tempo em que não declarar o tipo de uma variável era um crime capital em alguns países, mas as regras relaxaram nas últimas décadas e muitos (bons) compiladores podem inferir a diferença entre um INT e uma STRING sem que você metodicamente tenha que ir declarando variável por variável ou, na pior das hipóteses, emitir um alerta de que não compreendeu algo. No final, o código fica mais limpo, você ganha tempo livre para se concentrar onde a lógica é mais pesada e pode relaxar da obrigação de declarar todos os tipos.
Afinal, para que declarar o tipo se você vai acabar convertendo o valor depois mesmo, não é verdade? Quem nunca pegou um resultado em string e converteu para int porque a função que levou meses para criar só responde com string e a biblioteca com a qual ela tem que se comunicar só aceita int? Nada foi planejado, não tem arquiteto nessa bagunça e o serviço é para ontem. Vai reescrever sua função? Vai abrir a biblioteca? Não. Vai criar mais um processo, para poder converter e a máquina que se vire, a performance que aguente, já estava assim quando você chegou. Aquele tempo extra de processamento incomoda, te tira o sono pela ineficiência, mas refazer tudo do zero por falta de visão do futuro é algo que seria ainda mais ineficiente.
Programação orientada a objetos é uma ideia excepcionalmente ruim que só poderia ter se originado na Califórnia.
Mas se os tipos não foram talhados em mármore, o que dizer de operadores e funções? A partir deste ponto, talvez você devesse ter parado de ler mesmo, mas a perigosa verdade é que dependendo da linguagem de programação que você usa… é possível alterar a realidade. Em Python, por exemplo, é possível declarar que TRUE=FALSE e seu cérebro (e do cara que for dar manutenção) que se vire com esse universo paralelo. Dá para fazer a mesma coisa (ou pior) com pré-processadores em C e por aí vai. Não é preciso explicar o quanto isso pode explodir um projeto, às vezes literalmente. Entretanto, acredite, há casos em que esse é o melhor caminho.
Tomemos por exemplo uma total alteração do projeto. Dessas que nunca acontecem na vida real. Dessas que o cliente precisa para o mês passado. Você pode mergulhar em milhares de linhas de código para fazer a mudança. Ou pode mexer em algumas “constantes”. O que você faria? Cada célula do seu corpo grita que alterar a realidade é algo de supervilão de quadrinhos. Seu chefe grita mais alto e você acaba fazendo…
Nem sempre dá para seguir o manual, nem sempre dá para ser certinho, nem sempre dá para salvar o dia. Mas, às vezes, acabam se quebrando regras e salvando o projeto. E salve-se quem puder.
