Escolha com cuidado suas regras

É impressionante a facilidade com que certas discussões técnicas ficam parecendo discussões sobre moral, ética ou futebol. Parece que é difícil entender o fato de que fazer uma escolha técnica diferente da sua não vai condenar ninguém ao inferno.

Veja, por exemplo, a questão da validação do W3C. Algumas páginas do site da Visie não passam na validação do W3C. E a gente não está nem aí para isso. Entenda bem, nós acreditamos na importância dos padrões web. A empresa se chama “Visie Padrões Web”. Mas acreditamos que padrões web são importantes porque tornam seu site acessível, compatível, rápido e indexável. Também são importantes porque formam um excelente conjunto de tecnologias para o desenvolvimento. Desenvolver direito com padrões web é a melhor relação custo X benefício.

Nada disso tem a ver com estar “certo”, politicamente correto, ou com conseguir ganhar um selinho. Tem a ver apenas com encontrar a melhor maneira de deixar meus usuários satisfeitos. Ponto.

O validador é uma ferramenta e tanto. Principalmente para quem está aprendendo HTML ou precisa corrigir um problema misterioso num site. Eu uso muito o validador em treinamentos. Mas ele não é um juiz, um crivo obrigatório sem o qual seu site não deveria nem ser publicado.

Javascript

Javascript é uma linguagem muito flexível, que permite muitas escolhas diferentes de modelagem, de técnica de codificação e até de estilo do código. E isso é um terreno muito fértil para os inventores de regras. Existem mil maneiras de preparar Neston. Nenhuma é mais “certa” do que a outra, o que define o que é certo são seus objetivos.

Não, não estou falando sobre a polêmica dos ponto-e-vírgula no código. Embora esse seja um assunto interessante, não é tão importante. Estou falando de algo mais.

Leia, por exemplo, o excelente artigo do Willian Bruno sobre orientação a objetos. Antes de criticá-lo, preciso dizer que o Willian usou uma abordagem muito didática, e escreveu código impecável. Vale a pena a leitura. A única coisa que eu recomendo ao leitor é que entenda que a abordagem usada não é a única correta.

Começando com o estilo de código para orientação a objetos. Tem gente que escreve construtores de objetos literais, como o Willian fez. Tem gente que escreve funções construtoras, para ser chamadas com new, e atribuem propriedades e valores dentro do construtor. Tem gente que escreve funções construtoras e atribui propriedades e métodos ao seu prototype. Há grandes diferenças de sintaxe e ligeiras diferenças nos resultados obtidos ao usar cada técnica. O ponto é: não escolha as regras de alguém como as suas sem entender primeiro os porquês.

Outro ponto tem mais a ver com a modelagem do que com estilo de código. O Willian usa um pattern bastante popular hoje em Javascript, o Module. E faz com ele controle de visibilidade, fazendo com que apenas um método seja visível fora do módulo. Esse estilo de modelagem, embora bastante popular, está longe de ser o único correto. Embora programadores Java e C sejam incentivados a se preocupar muito com isso, a maioria dos programadores Ruby usa com muita parcimônia o controle de visibilidade e a comunidade Python tem vivido muito bem sem esse recurso. Você pode escrever módulos com excelente nível de encapsulamento sem controle de visibilidade.

A mesma coisa se aplica a quase qualquer escolha em tecnologia. NoSQL não é a bala de prata que vai salvar a próxima geração de ERPs, mas vale a pena conhecer. Os novos recursos do HTML5 não vão tornar a jQuery desnecessária, mas você precisa conhecê-los. O Sublime Text não me fez largar o Vim, mas valeu muito a pena gastar um tempinho para ter uma segunda opção.

Moderação. Não é futebol. Não é religião. É só técnica.