Nomear parâmetros com o mesmo nome de campos é uma má prática?

Acho que os programas são feitos para serem lidos por gente também, e você sabe que gente tem os seguintes problemas:

• Dificuldades com regras de escopo;
• Dificuldade para distinguir entre minúsculas e maiúsculas;
• Dificuldade para distinguir entre o l e o 1, o 0 e o O, o b e o 6, o B e o 8, o 2 e o Z.
• Dificuldade para contar _.

Portanto acho que é bom nomear os parâmetros com nome um pouco diferente dos campos, e evitar o uso excessivo de “this” - por exemplo (é o que configurei no meu Eclipse):

public void setColor (final Color pColor) {
    color = pColor;
}

ou, como já vi por aí, (embora não seja padrão e na verdade um pouco confuso - nunca lembro quem deve ter o “_”, se é o atributo da classe ou se é o parâmetro):

public void setColor (final Color color) {
    _color = color;
}

thingol:

Acho que os programas são feitos para serem lidos por gente também, e você sabe que gente tem os seguintes problemas:

• Dificuldades com regras de escopo;
• Dificuldade para distinguir entre minúsculas e maiúsculas;
• Dificuldade para distinguir entre o l e o 1, o 0 e o O, o b e o 6, o B e o 8, o 2 e o Z.
• Dificuldade para contar _.

Portanto acho que é bom nomear os parâmetros com nome um pouco diferente dos campos, e evitar o uso excessivo de “this” - por exemplo (é o que configurei no meu Eclipse):

public static void setColor (final Color pColor) {
    color = pColor;
}

ou, como já vi por aí, (embora não seja padrão e na verdade um pouco confuso - nunca lembro quem deve ter o “_”, se é o atributo da classe ou se é o parâmetro):

public static void setColor (final Color color) { _color = color; }

Jamais colocar “_” nem pColor, coloca literal o nome, p/ minha pessoa isso é uma boa prática.

public static void setColor (final Color parameterColor) {
    color = parameterColor;
}

Pelo menos é “entendivel”

Thingol, ainda prefiro o sobreamento.

public void setColor (final Color color) {  
     this.color = Color;  
 }

Onde você conseguiu configurar o nome do parâmetro gerado pelo eclipse para os setters? Procurei e não achei :roll:
Sabe se dá pra configurar isso pra geração de construtores também?

afsrj:

Thingol, ainda prefiro o sobreamento.

public void setColor (final Color color) {  
     this.color = Color;  
 }

Concordo.
E inclusive coloco meu eclipse a reclamar “Unqualified access to instance field”.

Ué, concordo! Os programas devem serfeitos para ser lidos por gente que conheça a linguagem em questão. Ou consideremos que desenvolvedores não são gente? Talvez não sejamos mesmo, mas até aí, nada provado a respeito disso… :lol:

discussão interessante aberta pelo Mantu.

na minha opinião temos que dosar essas duas coisas. Por exemplo, nos métodos gets e sets, que são relativamente simples, não há necessidade de se atribuir prefixos ou sufixos aos parâmetros, afinal, acho que todo bom programador é capaz de entender o código:

public void setNome( String nome ){
   this.nome = nome;
}

Mas, se for utilizar o parâmetro várias vezes em métodos complexos, além de atribuí-lo para o atributo de classe, aí sim, acho que vale a pena passar o parâmetro com nome diferenciado.

Mas também concordo com o Heero Yuy, se for para passar o parâmetro com nome diferenciado então que se dê um nome entendível.

Flw galera.

Alguém aí, pelo amor de Deus, sabe me dizer como configuro no eclipse aquilo que tingol falou que configurou no dele? E se dá pra fazer isso com construtores também?

acho que é…
Dentro das preferencias…
Java -> Code Style -> Code Template

Tem lá os templates

Valeu nbluis, mas já achei. Inclusive é quase onde você disse. Na verdade é diretamente em Java -> Code Style. Lá tem uma tabela chamada Conventions for variable names, é nesta tabela que conseguimos prefixar qualquer parâmetro, por exemplo

No Eclipse 3.2 você pode fazer: Project, Java Code Style, [X] Enable project specific settings, em Parameters edite “Prefix List” para o que você quiser (no meu caso “p”).

Se você prefere o shadowing, em vez disso marque a opção [X] Qualify all generated field accesses with “this.”

Como eu disse, acho que isso é questão de gosto (e de padrão dentro do seu projeto), então fiquem à vontade para fazerem do jeito que vocês quiserem.

Uma coisa que acho que ajuda muito é usar “final” em parâmetros (use com critério :P) ; isso ajuda a pegar alguns bugs estúpidos, como este:

public void setNome (final String pNome) {
    pNome = nome; // veja que aqui eu esqueci e mudei a ordem da atribuição sem querer :P
}

Usando o “final” esse erro é acusado pelo compilador.

Eu não acho que seja uma má prática, uma vez que existe o this para evitar problemas.

Concordo. No mínimo o cara (desenvolvedor) tem que conhecer a linguagem que está trabalhando.

nbluis:

afsrj:

Thingol, ainda prefiro o sobreamento.

public void setColor (final Color color) {  
     this.color = Color;  
 }

Concordo.
E inclusive coloco meu eclipse a reclamar “Unqualified access to instance field”.

Como fez para ele “reclamar”?

Preferences -> Java -> Compiler -> Erros/Warnings

Grato!

Acho que essa é uma boa prática em Java, porque é bem aceita na comunidade Java.

Se você fizer a mesma pergunta num fórum de C++, vai ver que a resposta é outra... e no C++ também é permitido

void UmaClasse::umMetodo(int umParametro) {
   this-&gtumParametro = umParametro;
}

Mas por lá ninguém é muito partidário dessa filosofia.

Eu também sou adepto porque há poucos casos que isso acontece fora dos construtores ou setters.
Para parâmetros, ok. Mas não gosto desse tipo de shadowing quando alguém cria uma variável com o mesmo nome do atributo, no meio do método. Mais feio ainda é usar sem o .this com dois contextos diferentes. Algo como:

public class UmaClasse {
   private int umAtributo = 0;

   public int umMetodo() {
      umAtributo++;
      int umAtributo = 10 + this.umAtributo;
      return umAtributo;
   }
}

thingol:

No Eclipse 3.2 você pode fazer: Project, Java Code Style, [X] Enable project specific settings, em Parameters edite “Prefix List” para o que você quiser (no meu caso “p”).

Se você prefere o shadowing, em vez disso marque a opção [X] Qualify all generated field accesses with “this.”

Como eu disse, acho que isso é questão de gosto (e de padrão dentro do seu projeto), então fiquem à vontade para fazerem do jeito que vocês quiserem.

Uma coisa que acho que ajuda muito é usar “final” em parâmetros (use com critério :P) ; isso ajuda a pegar alguns bugs estúpidos, como este:

public void setNome (final String pNome) {
    pNome = nome; // veja que aqui eu esqueci e mudei a ordem da atribuição sem querer :P
}

Usando o “final” esse erro é acusado pelo compilador.

Eu tbm uso sempre o ‘final’ nos métodos. Vc configurou para iserir isso automático ou faz na mão mesmo?