KISS!
Não, eu não estou louco, e também não estou dizendo que vou sair por aí beijando todo mundo. Esse KISS que falo é um acrônimo para “Keep It Simple, Stupid”, equivalente a “Mantenha Simples, Estúpido”, em português.
Também não estou chamando ninguém aqui de estúpido, não me entendam mal. Estava programando exaustivamente há horas, e resolvi dar uma passeada pela Internet. Lá pelas tantas, cheguei a um blog através das tags do WordPress, e encontrei esse acrônimo. O significado lá era o mesmo que dei aqui, mas vou dar umas dicas para KISS.
Comente seu Código
Por mais simples que seja seu código, comente-o. Acredite, na maioria das vezes vale a pena.
Há muito tempo você escreveu uma função, digamos, para ler XML e mostra-lo na tela (você anda bem experiente mesmo, neh?). Ou qualquer outra função. Aí você deixa ela paradinha lá na sua pasta de códigos por um bom tempo. Por acaso do destino, você volta a precisar daquela função, que não tem nenhum único comentário. E você também não lembra que tipo de técnica utilizou, e acabou adquirindo mais conhecimento para fazer diferente, e esqueceu de erros que cometia.
Isso seria um desastre. Você perderia vários minutos (ou horas, dependendo do tamanho e complexidade do código) tentando entender o código, para depois começar a trabalhar nele (ou com ele).
A coisa piora quando não é você que mexerá nesse código, o pesadelo duplica, triplica, quatriplica de tamanho. Imagine só.
Comentar um código não o simplifica, mas ajuda no processo. Sabe quando você vai comentar uma parte um tanto confusa? Resumindo: comentários, além de ajudar na compreensão de um código, são detectores de tolices, complexidade extra, excesso de código ou de pura e simples falta de simplicidade.
É claro que em funções simples isso não é necessário. É totalmente contraproducente.
Elimine Linhas de Código
Como tudo na Internet, e em qualquer computador, um caractere ocupa seu espaço. Uma linha também. Uma linha com caracteres então…
Linhas em branco e tabulações são importantes, mas há lugares em que são desnecessários. Não pule muitas linhas entre um bloco de código e outro, duas ou três é o suficiente.
Mas não é exatamente sobre essas linhas que falo. Vamos tomar como exemplo o nosso querido JavaScript. Podemos resumir blocos de código, como IF ELSE:
// "Errado"
if( condition ) { umaUnicaLinha(); }
else { outraLinha(); }
// Certo
if( condition ) umaUnicaLinha();
else outraLinha();
// Mais Certo Ainda - Expressão ternária
condition ? umaUnicaLinha() : outraLinha();
Entendeu? Viu quantos caracteres economizamos? Esses blocos podem ser resumidos se tiverem apenas uma linha, dispensado as chaves. E condições ternárias podem ser mais resumidas ainda.
Outra maneira de economizar código é diminuir tarefas repetitivas. Se você já fez um curso mais avançado de MS Word ou Excel, sabe disso (macros). Por exemplo, várias condições devem ser testadas várias vezes da mesma maneira. Em vez de colocar o teste por inteiro, criamos funções! Lógico, não? Isso deve vir desde o planejamento do script.
Em suma, aproveite todos os recursos da linguagem em que você programa para torna-la mais rápida, compacta e simples. Estude bem o que você programa.
Use Indentações
Com o código que economizamos ali acima, podemos usa-lo para tornar o código mais legível.
As indentações servem para identificar em que nível alguma instrução se encontra. Não precisam ser indentações muito grandes, dois espaços são o suficiente. Um só dificulta a compreensão de muitos níveis, e tabulações (tecla TAB), em caso de muitos níveis, tornam difícil de ler, pois tiram o código mais indentado do campo de visão do editor.
Indentar é extremamente simples, mas se torna chato às vezes. Por isso, um bom editor ajuda, mantendo as indentações no lugar depois de um Enter.
Se você já viu o código padrão do Invision PB, deve saber do que falo. Aquilo é incompreensível. Tudo fica na mesma linha, no mesmo nível. Faça o possível para tornar seu código, acima de tudo, legível para você, depois para os outros, e depois para as máquinas. Acredite, facilita bastante.
Nomeie Corretamente
Essa parte foge um pouco do tema principal, mas já que estou dando umas dicas…
Procure dar nomes intuitivos às suas funções, atributos, blocos de código, enfim… O Diego Eis, do Tableless, escreveu um artigo muito interessante sobre nomear classes corretamente. Esse artigo pode também ser aplicado a qualquer coisa, que já citei a pouco.
Dê nomes intuitivos para tudo que criar. Esses nomes devem ter algo a ver com o que você criou, e não onde está posicionada ou o que faz apenas, e somente apenas no que resulta em uma única condição (por exemplo: uma função Ajax complexa que retorna XML e texto, ser chamada de AjaxText, isso é errado).
Poderiam ser citados vários outros pontos, mas eles fugiriam um pouco mais do que quero aqui. Em resumo, o que vale é a simplicidade, legibilidade e total e completa compreensão por humanos, pessoas, gente, nós, enfim…






