Eu venho de linguagens como Python ou Javascript (e outras que são menos orientadas a objeto) e estou tentando melhorar meu conhecimento de trabalho em Java, que eu conheço apenas superficialmente.
Considera-se uma prática ruim sempre preceder this aos atributos da instância atual? Parece mais natural para mim escrever
...
private String foo;
public void printFoo() {
System.out.println(this.foo);
}
...
do que
...
private String foo;
public void printFoo() {
System.out.println(foo);
}
...
porque me ajuda a distinguir atributos de instâncias de variáveis locais.
É claro que, em uma linguagem como Javascript, faz mais sentido usar sempre this , pois é possível ter mais aninhamento de função, portanto, variáveis locais provenientes de escopos maiores. Em Java, pelo que eu entendo, nenhum aninhamento como esse é possível (exceto para classes internas), então provavelmente não é um grande problema.
De qualquer forma, eu preferiria usar this . Seria estranho e não idiomático?
Na maioria dos IDEs, você pode simplesmente passar o mouse sobre a variável se quiser saber. Além disso, realmente, se você está trabalhando em um método de instância, você deve conhecer realmente todas as variáveis envolvidas. Se você tem muitos, ou seus nomes se chocam, então você precisa refatorar.
É realmente muito redundante.
Eu prefiro usar this . Isso facilita a leitura de código em vários editores que colorem variáveis locais e de instância da mesma maneira. Também facilita a leitura do código em uma página impressa durante algo como uma revisão de código. Também é um lembrete bastante strong quanto ao escopo da variável para outros desenvolvedores.
No entanto, existem argumentos contra isso. Nos IDEs modernos, você pode descobrir o escopo de uma variável passando o mouse sobre ela ou visualizando-a em uma estrutura semelhante a uma árvore. Você também pode alterar a cor e / ou a face da fonte das variáveis dependendo do seu escopo (mesmo de forma que, quando impressa, seja evidente qual é o escopo da variável).
Acredito que A última sentença de ChrisF está morta: seja consistente em seu uso.
Um lugar onde eu uso consistentemente 'this' são setters e ou construtores:
public void setFoo(String foo) {
this.foo = foo;
}
Além disso, não acho necessário adicioná-lo. Ao ler o corpo de um método, os parâmetros e os locais estão bem ali - e bastante fáceis de acompanhar (mesmo sem a ajuda do IDE). Também locais e campos tendem a ser de natureza diferente (estado do objeto vs armazenamento ou parâmetro transitório).
Se houver alguma confusão sobre o que é uma variável e o que é um campo, isso provavelmente significa que um método tem muitas variáveis / parâmetros, é muito longo e complexo demais e deve ser simplificado.
Se você optar por usar 'this' para marcar campos, recomendo que a convenção seja sempre rigorosamente seguida. Seria muito fácil começar assumindo que 'isso' significa que é um material local e de interrupção baseado no suposição.
edit: Eu também acabo usando isso em equals, clone ou qualquer coisa que tenha um parâmetro 'that' do mesmo tipo de objeto:
public boolean isSame(MyClass that) {
return this.uuid().equals(that.uuid());
}
É discutível.
Tomando o C # como uma analogia, pois tem uma sintaxe e estrutura muito semelhantes ao Java, descobrimos que C # StyleCop tem uma regra padrão que insiste em adicionar this , mas o ReSharper tem uma regra padrão que diz que this é redundante (que é) e pode ser removido.
Então, se você estiver usando uma ferramenta, você as adicionará, mas, se usar outra, irá removê-las. Se você estiver usando as duas ferramentas, terá de escolher e desativar uma das regras.
No entanto, o que as regras significam é que você é consistente em seu uso - que é provavelmente a coisa mais importante.
Is it considered a bad practice to always prepend this to the current instance attributes?
Sim - por alguns, não - por outros.
Eu gosto e uso a palavra-chave this em meus projetos em Java e C #. Pode-se argumentar que o IDE irá sempre destacar parâmetros e campos por cores diferentes, mas nem sempre trabalhamos em IDE - temos que fazer muitas mesclagens / diffs / algumas mudanças rápidas em um bloco de notas / verificar alguns trechos de código em e-mail . É way mais fácil para eu identificar desde o primeiro olhar onde o estado da instância é alterado - por exemplo, para rever alguns possíveis problemas de concorrência.
Eu acho que se você precisar usar isso, você tem um método que é muito longo, ou uma classe que está tentando fazer muito, ou ambos.
Os métodos nunca devem ter mais que algumas linhas de código, use uma ou duas variáveis locais, determinando o que é fácil; mesmo com apenas o contexto de 3 linhas da maioria das ferramentas diff. Se seus métodos forem muito longos e suas classes tiverem muitas responsabilidades (muitas vezes significando muitos campos), a solução é dividi-las.
Eu acho que "isso" apenas desordena o código. Especialmente com os IDEs modernos que colorem parâmetros locais / variáveis locais / campos de maneira diferente.
Acho que você respondeu sua própria pergunta com isso:
It feels more natural to me to write
... this.foo ...
than
... foo ...
as it helps me to distinguish instance attributes from local variables.
Se você estiver mais confortável usando this. enquanto melhora seu conhecimento de trabalho com Java, então use a coisa ( eu acho que é, de certa forma, o familiar Python self com o qual você está se relacionando ).
A questão é que, embora as pessoas dêem argumentos sólidos / pertinentes sobre o uso ou não de this. , ainda soa como um debate, exemplo dado:
this. é redundante se você passar o dia inteiro no IDE vs. Eu realizo revisões de código e faço comparações em versões diferentes usando um comparador sem realce de sintaxe; this. me ganha milésimos de segundo de produtividade xe. Eu pago pela tecla pressionada e adicionando this. é como um aumento de salário: D; Mas, no final das contas, é que, no final do dia, ele continua voltando à preferência pessoal e ao ambiente de trabalho .
Normalmente adicionar isto é desnecessário. Eu não acho que seja má prática em si, mas o uso excessivo de isso provavelmente seria considerado incomum na maioria das bases de código Java que eu vi.
No entanto, acho isso valioso em algumas situações específicas:
Substituindo parâmetros locais - às vezes é necessário especificar que você deseja usar uma variável de instância em vez de uma variável de parâmetro / local com o mesmo nome. Isso é bastante comum em construtores, onde você deseja que o nome do parâmetro corresponda ao nome interno da variável de instância usada para inicializar, por exemplo,
class MyObject {
int value;
public MyObject(int value) {
this.value=value;
}
}
Ao lidar com outras instâncias da mesma classe , acredito que torne o código mais claro e mais compreensível para ser explícito a que instância da classe você está se referindo, por exemplo
class MyObject {
int value;
....
public MyObject add(MyObject other) {
return new MyObject( this.value + other.value )
}
}
Tags coding-style java