Java`da `this` anahtar sözcüğünü kullanmak için kabul edilen stil nedir?


37

Python veya Javascript (ve daha az nesne yönelimli diğerleri) gibi dillerden geliyorum ve Java'nın çalışma bilgimi, sadece yüzeysel bir şekilde bildiğim şekilde geliştirmeye çalışıyorum.

thisMevcut örnek niteliklerine her zaman hazırlanmak kötü bir uygulama olarak mı kabul edilir ? Yazmak bana daha doğal geliyor.

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

göre

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

örnek niteliklerini yerel değişkenlerden ayırt etmeme yardımcı oluyor.

Elbette Javascript gibi bir dilde kullanmak her zaman daha mantıklıdır this, çünkü biri iç içe geçme işlevine sahip olabileceğinden, yerel değişkenler daha geniş kapsamlardan gelir. Java'da, anladığım kadarıyla, böyle bir yuva mümkün değildir (iç sınıflar hariç), bu yüzden büyük bir sorun değildir.

Her durumda kullanmayı tercih ederim this. Aptalca değil, garip hissettirir mi?


Şirketimizde yer almak için bir araç kullanıyoruz. Aracı şirket politikasına bağlı olarak bu olmadan bizim kodunu rerite. Böylece, herkes istediklerini ve kodlama işleminin doğru şekilde nasıl yapıldığını kodlar.
deadalnix

2
"biri daha fazla fonksiyon yuvalamaya sahip olabileceğinden, yerel değişkenler daha geniş kapsamlardan geliyor." Ayrıca, "bu" nun aslında niteliksiz bir değişkenin JS'deki bir fonksiyondan gelebileceği yerlerden biri olmadığı gerçeği.
Random832

2
Tüm örnek değişkenlerini alt çizgi ile öneklendiririm, böylece yerel ve örnek değişkenler arasındaki farkı kullanmadan kolayca söyleyebilirim this.
WuHoUnited

4
C # StyleCop this.üye değişkenleri, yöntemleri, vb. Atıfta zaman koymak istiyor . Bu gibi, bu kuralı kabul ediyorum. En başında bir alt çizgi bulunan bir şeyi adlandırmaktan daha iyi olduğunu düşünüyorum. Java'da kod yazıyor olsam da aynı kuralı izlerdim.
İş

Yanıtlar:


40

Çoğu IDE'de bilmek istiyorsanız değişkeni basitçe fareyle değiştirebilirsiniz. Ek olarak, gerçekten, bir örnek yönteminde çalışıyorsanız, ilgili tüm değişkenleri gerçekten bilmeniz gerekir. Çok fazla varsa veya isimleri çakışırsa, yeniden ateşlemelisiniz.

Gerçekten çok gereksiz.


7
Ayrıca: Aklı başında bir IDE alanları ve yerel değişkenleri / parametreleri görsel olarak ayırt etmelidir. Örneğin Eclipse'de (varsayılan olarak) alanlar mavi, yerel değişkenler ise siyahtır.
Joachim Sauer

1
@Joachim Nice point, Eclipse, kullanıcı isterse parametreleri ve yerel değişkenleri farklı şekilde renklendirebilir (ancak bu varsayılan olarak değildir).
Eric-Karl

3
Buna rağmen, diğer geliştiricilerin koduyla karşılaşırken (ve ilk bakışta tanıdık olmadıklarında) this.çok daha yararlı buluyorum . Bunun nedeni muhtemelen yerel / nesne değişkenlerini farklı renk kodlayan bir IDE'ye sahip olmamamdır.
Brad Christie,

3
+1 (baskısından başka) "Kullanmak gerekiyorsa refactor bu bir üyesi olduğunu anlamak için". Sadece işaret etmek istediğim şeyi.
Yam Marcovic

Okumayı zorlaştırıyor ve karşılığında kodları, alanlar ve yerliler arasında ayırt etmeyen, daha az karmaşık sözdizimi vurgulayan editörlerde okunabiliyor. Kodunuzun en basit metin editöründe kolayca okunabilmesi için çaba göstermeniz gerektiğine ve her zaman bunun için iyi bir neden olması gerektiğine dair her zaman fikrim vardı.
Kevin

26

Kullanmayı tercih ederim this. Yerel ve örnek değişkenleri aynı şekilde renklendiren çeşitli editörlerde kod okumayı kolaylaştırır. Ayrıca, kod incelemesi gibi bir şey sırasında yazdırılan sayfadaki kodu okumayı kolaylaştırır. Aynı zamanda, diğer geliştiricilere değişkenin kapsamı hakkında oldukça güçlü bir hatırlatmadır.

Ancak buna karşı tartışmalar var. Modern IDE'lerde, bir değişkenin kapsamını üzerinde gezerek veya ağaç benzeri bir yapı içinde görüntüleyerek bulabilirsiniz. Ayrıca, değişkenlerin renk ve / veya yazı tipi yüzlerini, kapsamlarına bağlı olarak da değiştirebilirsiniz (bu şekilde bile, yazdırıldığında değişkenin kapsamı açıktır).

ChrisF'in son cümlesinin öldüğüne inanıyorum : kullanımınız için tutarlı olun.


7
“Ayrıca, diğer geliştiricilere olan değişkenin kapsamı hakkında oldukça güçlü bir hatırlatma.” - kullanımda ve this.kodda görmekten hoşlanmamın nedeni . Yazmak için yarım saniye alır ve sizden önce olan adamın, 20 dakika önce bu son dakikayı değiştirdiğinde son dakika patlamasını yaptığında deve-davası yerine pascal-case özelliğini kullanmak isteyip istemediğini anlamak zorunda kaldığınızda uzun dakikalar kazanabilirsiniz.
scrwtp

18

Sürekli olarak 'this'i kullandığım bir yer, düzenleyiciler ve / veya yapıcılar:

public void setFoo(String foo) {
    this.foo = foo;
}

Bunun dışında, onu eklemenin gerekli olduğunu düşünmüyorum. Bir yöntemin gövdesini okurken, parametreler ve yerliler tam oradadır - ve takip etmesi oldukça kolaydır (IDE yardımı olmadan). Ayrıca yerliler ve alanlar da farklı niteliktedir (nesne durumu - geçici depolama veya parametre gibi).

Değişken ve alan nedir hakkında herhangi bir karışıklık varsa, bu muhtemelen bir yöntemin çok fazla değişkene / parametreye sahip olduğu, çok uzun ve çok karmaşık olduğu ve basitleştirilmesi gerektiği anlamına gelir.

Alanları etiketlemek için 'this'i kullanmayı seçerseniz, konvansiyonun daima sıkı bir şekilde takip edildiğinden emin olmanızı tavsiye ederim -' bu'nun hiçbir şeyin yerel olduğu ve varsayımlara dayanan bir şey olmadığı anlamına gelmediğini varsaymak gerçekten kolay olacaktır.

edit: Ayrıca, aynı nesne tipinde 'that' parametresine sahip olan bir eşittir, klon veya herhangi bir şeyle bunu kullanıyorum:

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

8

Bu tartışılabilir.

C # 'yı Java ile benzer bir sözdizimine ve yapısına sahip olduğu gibi bir analoji olarak alarak, C # StyleCop’un eklemek için ısrar eden varsayılan bir kural olduğunu this, ancak ReSharper’ın thisgereksiz olduğunu (yani olduğunu) ve çıkarıldı.

Yani bir araç kullanıyorsanız onları ekleyeceksiniz ama eğer bir başkasını kullanıyorsanız bunları kaldıracaksınız. Her iki aracı da kullanıyorsanız, kurallardan birini seçmeniz ve devre dışı bırakmanız gerekir.

Bununla birlikte, kuralların anlamı, kullanımınız için tutarlı olmanızdır - ki bu muhtemelen en önemli şeydir.


8

Bunu her zaman mevcut örnek özelliklerine hazırlamak için kötü bir uygulama olarak mı kabul edilir?

Evet - bazıları tarafından, hayır - diğerleri tarafından.

Sevdiğim ve kullanım thisJava ve C # benim projelerde anahtar kelime. Biri IDE'nin parametreleri ve alanları her zaman farklı renklerle vurgulayacağını, ancak IDE'de her zaman çalışmadığımızı iddia edebilir - bir not defterinde çok fazla birleştirme / fark / bazı hızlı değişiklikler yapmak / e-postadaki bazı kod parçacıklarını kontrol etmek zorundayız. . Bu var yolu , örneğin bazı olası eşzamanlılık sorunları inceleyecek - Beni örneğinin devlet değiştiğinde ilk bakıştan noktaya kolaylaştırır.


7

Bunu kullanmanız gerekirse, ya çok uzun bir yönteme ya da çok fazla yapmaya çalışan bir sınıfa ya da her ikisine de sahip olduğunuzu düşünüyorum.

Yöntemler asla birkaç kod satırından daha uzun olmamalıdır, neyin kolay olacağını belirleyen bir ya da iki yerel değişken kullanın; çoğu diff aracının sadece 3 satırlı içeriğiyle bile. Yöntemleriniz çok uzunsa ve sınıflarınızın çok fazla sorumluluğu varsa (genellikle çok fazla alan anlamına gelir), çözüm bunun yerine onları bölmektir.

Bence "bu" sadece kod debutters. Özellikle yerel parametreleri / yerel değişkenleri / alanları farklı şekilde renklendirecek modern IDE'ler.


5

Sanırım kendi sorunuzu bu şekilde cevapladınız :

Yazmak bana daha doğal geliyor.

... this.foo ...

göre

... varsayılan değer ...

örnek niteliklerini yerel değişkenlerden ayırt etmeme yardımcı oluyor.

this.Java ile çalışma bilginizi geliştirirken daha rahat olursanız, elbette ki bu şeyi kullanın ( bir şekilde, ilgili olduğunuz tanıdık Python benliği olduğunu düşünüyorum ).

Mesele şu ki, insanlar kullanma veya kullanmama konusunda sağlam / uygun tartışmalar sunsalar da this., yine de bir tartışma gibi göründüler.

  • o değişkenlerin amacı temizlemek yapar vs her değişken ne olduğu açık değilse kodu yazarsın bundan;
  • this.ıde tüm gün geçirmek eğer gereksiz vs ben vurgulama hiçbir sözdizimi ile bir karşılaştırıcı kullanılarak farklı sürümleri üzerinde kod yorum ve marka diffs gerçekleştirmek;
  • Yazmadığınız this.kazanımlar beni verimliliğin önemli milisaniye vs ben anahtar ile ödenir olsun preslenmiş ve ekleme this.maaş zammı gibidir: D;
  • vs vs

Ancak, sonuçta, günün sonunda, yine de kişisel tercih ve çalışma ortamına devam ettiğidir .


5

Normalde ekleyerek bu gereksizdir. Ben se başına kötü bir uygulama olduğunu düşünmüyorum, ama aşırı bir şekilde kullanılması bu muhtemelen gördüğüm çoğu Java kod üsleri sıradışı kabul edilecektir.

Ancak bunu birkaç özel durumda değerli buluyorum:

Yerel parametreleri geçersiz kılma - bazen aynı isimde bir parametre / yerel değişken yerine örnek değişken kullanmak istediğinizi belirtmeniz gerekir. Yapıcılarda bu oldukça yaygındır; burada parametre adının, örneğin ilklendirmek için kullanıldığı örnek değişkenin iç adıyla eşleşmesini istediğinizde

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

Aynı sınıfın diğer örneklerini kullanırken kodun, sınıfın hangi örneğine atıfta bulunduğunuzu açıkça belirtmenin açık ve anlaşılır kıldığına inanıyorum.

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.