Javascript anti-patterns – Nomenclatura

Olá meus queridos!

Acho que eu não cheguei a falar sobre nenhum anti-pattern no blog, pelo menos não que me lembre… Postei bastante sobre padrões e com o passar do tempo você começa a se perguntar se aquilo que acredita faz sentido ou não.

Gostaria de discutir um assunto que é meio polêmico, que é o modo como você padroniza a nomenclatura das suas variáveis no Javascript.

É claro que estas são as minhas opiniões e em algum momento eu posso entrar em contradição em algumas delas, porque no final tudo está relacionado com o que gostamos ou não, é puramente uma questão de gosto.

Anti-pattern – pParameter

Este foi um dos primeiros anti-patterns que eu não entendia. A idéia aqui era colocar um antes do nome da variável para indicar que esta era um parâmetro de função.


function set( pName, pValue ){

my.object.name = pName || '';
 my.object.value = pValue || {};

}

Eu não estava muito certo do porque saber que uma variável vinha de parâmetro ou não era tão importante. Afinal de contas, é apenas uma variável.

Se você perde o tracking das variáveis das suas funções, isso pode significar que sua função está desnecessariamente complicada e/ou ilegível. Ao invés de simplificar a lógica, separar melhor as tarefas entre mais funções, as pessoas acreditam que é melhor criar um padrão para solucionar algo que pode não ser o verdadeiro motivo para um código difícil de se entender.

Escrever um nome que faça sentido, sucinto e simples ajuda muito mais a entender o que está fazendo do que padrões desnecessários.

function create( name, properties ){

    my.object.name = name || '';
    my.object.value = properties || {};

}

Anti-pattern – _underline

Diferentemente do padrão anterior, este é um conceito aprovado mundialmente… O que me deixa extremamente espantado… Independente do gosto, este “padrão” é inútil.

O argumento usado nesse padrão é que, se você constrói um objeto que possui um método privado, você deveria colocar um “_” antes para avisar o programador de que aquilo se trata de um método privado:

    function myModule(){
        return {

            _naoUse :function(){
                // Tudo o que faz o código funcionar
                // Está aqui
            },

            use :function(){
                this._naoUse();
                // Tudo o que é seguro e pode ser usado
                // Por qualquer programador é feito aqui
            }
        }
    }

Eu tenho quase certeza de que este padrão, pelo menos no Javascript, foi pensado por alguém que não conhecia muito bem a linguagem.

O Javascript possibilita nativamente dois níveis de visibilidade para variáveis, ou uma variável é privada ou é pública. Simples assim… qualquer coisa diferente disso é uma implementação para tentar reproduzir outros tipos, ou uma viagem dos gênios por trás do ES6 e ES7.

O fato é, nestes últimos 10 anos programando na linguagem, eu nunca precisei de nenhum outro nível de visibilidade.

A minha dica é, quando você cria um objeto que precisa ter interface com o mundo exterior, implemente esta interface utilizando métodos públicos e quando alguma lógica é essencial para manter o funcionamento coerente do seu objeto e não deve ser acessado de fora, implemente-a utilizando variáveis e métodos privados.

    function myModule(){

        var tenhoAlma;

        function codigoProtegido(){
            //O core do seu objeto deve ser protegido
            //de forma privada

            tenhoAlma = true;
            //Ninguém pode me tirar a alma
        }

        return {

            use :function(){

                codigoProtegido();
                // Tudo o que é seguro e pode ser usado
                // Por qualquer programador é feito aqui
            }
        }
    }

Leia mais sobre Closures em Javascript, sabendo disso, começa a entender como proteger seu código.

Aconselho também a ler sobre Information Hidding Encapsulation. Estes conceitos de orientação à objetos são muito mais valiosos para você do que padrões desnecessários.

Ah… se o motivo para usar underline é informar que o método é perigoso, bom… se você pudesse criar um botão para destruir sua casa, você o criaria e deixaria um bilhete informando as pessoas que não devem apertar?

Anti-pattern – $variable

Eu acho que tudo aquilo que vai contra os nossos princípios nos incomoda. Mas existem certas coisas que nos fazem querer mandar matar. Este é um dos anti-patterns que mais me irritam e um dos mais recentes.

Eu acredito que tenha sido criado graças à mais popular das bibliotecas javascript, a jQuery.

A idéia aqui é colocar um antes do nome da variável para indicar ao programador que está lidando com um objeto jQuery ao invés de um [HTMLNodeElement].

Seu código fica tão bonito quanto uma bunda suja e peluda:

    function ohGod( $element, $html ){

        $element.remove();
        $html.addClass( 'ready' );
        $html.append($element);
        $element.addClass('droped');
    }

Eu não sei vocês… mas a impressão que eu tenho é de que estou vendo um código php. Eu não tenho nada contra php, aliás eu gosto muito desta linguagem, só que o problema aqui é que estamos programando em Javascript.

O que torna mais estranho pra mim é que o mesmo programador que bota $ para avisar que está lidando com um objeto jQuery, é o mesmo que não coloca obj, arr, str, num, antes das variáveis, uma grande incoerência.

Ou seja, todos os outros objetos do javascript não tem importância saber o que são, só há importância saber se é um jQuery. Afinal de contas, você só pode se confundir com este tipo de objeto né?

Óbvio que não… colocar obj, arr, str, num, $ é o que mais me dói, porque isso é falta de conceito puro da linguagem.

Conceitualmente se você coloca numVariavel para dizer que é um número, você também estaria correto em colocar objVariavel para a mesma variável, porque número é um objeto aqui. Mais do que isso, podemos ter uma infinidade de objetos criados para um propósito específico, você vai criar um prefixo para cada um deles?

O maior poder da linguagem é o fato dela ser dinâmica, isto significa que uma variável que é string num momento, pode virar um objeto em outro momento. Não precisa se desesperar com este dinamismo, nem tentar “resolver” este “problema”. Isto NÃO É UM PROBLEMA. 

Então o que?

Ponha uma coisa na cabeça, o que faz o código ficar ilegível é sua falta de coerência, a falta de organização, uma arquitetura equivocada…isto não tem nada haver com a linguagem ou com falta de padrões ou anti-padrões.

Um programador que usa uma variável só e fica reescrevendo ela o tempo todo vai ter um código ruim independente da linguagem. Colocar prefixos para te alertar sobre o tipo da variável é no mínimo um contra-senso nesta linguagem, se tiver 20 menções da mesma variável no código, e precisar mudar o seu tipo, espero que não queira fazer um find/replace para mudar o nome dela para o tipo novo escolhido…

Se você ao olhar para o código tem a necessidade desesperadora de saber seu tipo, escolha outra linguagem, fuja de Ruby e Javascript. Eu sugiro C/C++, Java ou C#.

Programadores Javascript tem inúmeras vantagens em comparação à programadores de outras linguagens. Nós já sabemos há muito tempo que programar comportamentos é melhor do que acoplar nossas classes através de heranças clássicas. Naturalmente a linguagem nos força a programar assim…

Você pode treinar seu olho e sua mente para pensar de forma dinâmica, para se programar nestas linguagens devemos pensar em duck typing. Programamos comportamentos, portanto:

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.

Não criem padrões para ajudá-los a entender a linguagem. Gastem este tempo para aprender a mesma. Nada vai garantir que outras pessoas sigam o seu padrão. Saibam fazer contas, com laranjas, bananas e maças.

A igualdade 3x+9 = 0 também pode ser reescrita como 3y+9 = 0, você deve saber resolver das duas formas, não padronize a matemática se tem problema com a variável y.

Sem preguiça, olhe o código como quem gosta da linguagem, acostume-se a entender como identificar os tipos.

Desafio

Vou fazer um teste agora, usando a psicologia reversa, geralmente quando existe um desafio todo mundo deixa a preguiça de lado pra mostrar o quão melhor que os outros é…

Abaixo segue um código simples em javascript. Consegue me dizer quais são os tipos das variáveis existentes no código abaixo?

    function desafio( container, paragraph ){

        var name, lastname, age, person, nodeName;

        name = 'Angus';
        lastname = 'Young';
        age = 60;
        nodeName = document.createTextNode( person + ' ' +lastname );

        person = {
            name :name,
            lastname :lastname,
            age : age
        };

        paragraph.appendChild( nodeName );
        container.append( paragraph );

        return person;
    }

 

Vai me dizer que leva muito tempo para identificar quais são as variáveis do tipo nodeElement e qual é a do tipo jQuery…

 

Anúncios

5 comentários sobre “Javascript anti-patterns – Nomenclatura

  1. Ótimo post, acompanhado seu blog a alguns anos. Que bom que voltaste s escrever.
    Vou repensar melhor os códigos depois dessa :p
    Abs

    • Obrigado xará!

      Eu to ligado que está sempre por aqui, os comentários de vocês me motivam a escrever mais e compartilhar algumas idéias e opiniões… Obrigado novamente =)

    • Eu que agradeço sua participação aqui Lucas! Lembrando que exponho as minhas opiniões, e se sair daqui com algo como aprendizado, espero que seja o de parar para pensar sobre as coisas, pois muito o que escrevi é uma opinião pessoal. =)

      Um abraço!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s