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

Olá pessoal!
Estive conversando com alguns colegas e caímos em uma discussão a respeito de parâmetros de métodos com o mesmo nome de campos da classe. Alguns colegas pregaram que é má prática fazer isso.
Bom, eu, por enquanto, discordo.
Primeiro, porque existe uma coisa chamada escopo, que faz parte da linguagem. Existem meios “legais” de dirimir uma ambiguidade de escopo (this, por exemplo).
Segundo, porque o código começa a ficar “sujo” se tivermos que prefixar ou sufixar os parâmetros só para terem nome diferente dos campos. Tendo o programador claras as regras de escopo de identificadores, torna-se desnecessária a adição de prefixos, sufixos e, o pior caso de todos, abreviações.
Terceiro, dependendo da IDE que se utiliza, acabamos até mesmo a anular um pouco da produtividade conferida pela IDE. No Eclipse, por exemplo, ele pode gerar os getters e os setters para nós, e ele já gera os setters com os parâmetros com mesmo nome do campo. Vejo um retrabalho desnecessário em ter que passar depois em cada um dos setters e ficar prefixando os campos.
Quarto, e não menos importante, fica mais claro e legível para o desenvolvedor que vai utilizar um método se os nomes dos parâmetros forem objetivos, sem prefixos, sufixos, etc.

Gostaria que os colegas contribuissem com suas opiniões a respeito desse assunto. Pois derrepente podem aparecer visões da questão que não estou enxergando no momento.

Valeu, pessoal!

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;
}

[quote=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; } [/quote]

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”

:smiley:

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?

[quote=afsrj]Thingol, ainda prefiro o sobreamento.

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

[/quote]

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.

[quote=nbluis][quote=afsrj]Thingol, ainda prefiro o sobreamento.

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

[/quote]

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

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:

[code]public class UmaClasse {
private int umAtributo = 0;

public int umMetodo() {
umAtributo++;
int umAtributo = 10 + this.umAtributo;
return umAtributo;
}
}[/code]

[quote=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. [/quote]

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