जावा में `this` कीवर्ड का उपयोग करने के लिए स्वीकृत शैली क्या है?


37

मैं पायथन या जावास्क्रिप्ट (और अन्य जो कम ऑब्जेक्ट-ओरिएंटेड हैं) जैसी भाषाओं से आता हूं और मैं जावा के अपने काम के ज्ञान में सुधार करने की कोशिश कर रहा हूं, जिसे मैं केवल सतही तरीके से जानता हूं।

क्या इसे thisवर्तमान उदाहरण के गुणों के लिए हमेशा प्राथमिकता देना एक बुरा अभ्यास माना जाता है ? मुझे लिखना अधिक स्वाभाविक लगता है

...
private String foo;

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

से

...
private String foo;

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

चूंकि यह मुझे स्थानीय चर से उदाहरण विशेषताओं को भेद करने में मदद करता है।

बेशक, जावास्क्रिप्ट जैसी भाषा में, यह हमेशा उपयोग करने के लिए अधिक समझ में आता है this, क्योंकि एक में अधिक फ़ंक्शन नेस्टिंग हो सकती है, इसलिए बड़े स्कोप से आने वाले स्थानीय चर। जावा में, जहां तक ​​मैं समझता हूं, इस तरह का कोई घोंसला संभव नहीं है (आंतरिक कक्षाओं को छोड़कर), इसलिए शायद यह कोई बड़ा मुद्दा नहीं है।

किसी भी मामले में, मैं उपयोग करना पसंद करूंगा this। क्या यह अजीब लगेगा और मुहावरेदार नहीं?


हम एक उपकरण का उपयोग करते हैं जो हमारी कंपनी में है। कंपनी नीति के आधार पर इसके बिना हमारे साथ टूल रीराइट कोड। इसलिए कोई भी कोड को पसंद करता है कि वे कैसे पसंद करते हैं और कोड को प्रतिबद्ध समय पर सही तरीके से स्वरूपित किया जाता है।
डेडलिंक

2
"चूंकि एक से अधिक फ़ंक्शन घोंसले के शिकार हो सकते हैं, इसलिए बड़े स्कोप से आने वाले स्थानीय चर।" इसके अलावा, तथ्य यह है कि "यह" वास्तव में उन जगहों में से एक नहीं है जहां एक अयोग्य चर जेएस में एक फ़ंक्शन से आ सकता है।
रैंडम 832

2
मैं सभी उदाहरण चर को अंडरस्कोर के साथ उपसर्ग करता हूं ताकि मैं बिना उपयोग किए आसानी से स्थानीय और उदाहरण चर के बीच का अंतर बता सकूं this
वूहोइन्टेड

4
C # में StyleCop आपको this.सदस्य चर, विधियों आदि का जिक्र करते समय रखना चाहता है । मुझे यह पसंद है, मैं इस नियम से सहमत हूं। मुझे लगता है कि शुरुआत में अंडरस्कोर के साथ कुछ नामकरण करने से बेहतर है। अगर मैं जावा में कोडिंग कर रहा था तो मैं उसी नियम का पालन करूंगा।
अय्यूब

जवाबों:


40

अधिकांश IDEs में, यदि आप जानना चाहते हैं, तो आप केवल चर का माउसओवर कर सकते हैं। इसके अलावा, वास्तव में, यदि आप एक इंस्टेंस विधि में काम कर रहे हैं, तो आपको वास्तव में शामिल सभी चर पता होना चाहिए। यदि आपके पास बहुत सारे हैं, या उनके नाम टकराते हैं, तो आपको रिफ्लेक्टर करने की आवश्यकता है।

यह वास्तव में काफी बेमानी है।


7
इसके अलावा: एक सामान्य आईडीई को फ़ील्ड और स्थानीय चर / पैरामीटर को नेत्रहीन अलग बनाना चाहिए। उदाहरण के लिए एक्लिप्स (डिफ़ॉल्ट रूप से) फ़ील्ड नीले हैं, जबकि स्थानीय चर काले हैं।
Joachim Sauer

1
@Joachim अच्छा बिंदु, ग्रहण भी रंग मापदंडों और स्थानीय चर अलग-अलग कर सकते हैं यदि उपयोगकर्ता चाहता है (यह डिफ़ॉल्ट रूप से नहीं है)।
एरिक-कार्ल

3
हालांकि मैं सहमत हूं, जब अन्य डेवलपर्स कोड में आ रहा है (और पहली नज़र में अपरिचित होने के दौरान) मुझे this.बहुत अधिक उपयोगी लगता है। यह शायद इसलिए भी है क्योंकि मेरे पास एक आईडीई नहीं है जो रंग-कोड स्थानीय / ऑब्जेक्ट चर अलग-अलग है।
ब्रैड क्रिस्टी

3
+1 के लिए (विरोधाभास) "रिफैक्टर यदि आपको यह उपयोग करने की आवश्यकता है कि यह एक सदस्य है"। बस मैं क्या कहना चाहता था।
यम मार्कोविच

मुझे नहीं लगता कि इसे पढ़ना कठिन है, और बदले में, कोड संपादकों में पठनीय रहता है जिसमें कम परिष्कृत सिंटैक्स हाइलाइटिंग होता है जो खेतों और स्थानीय लोगों के बीच अंतर नहीं करता है। मेरी हमेशा यह राय रही है कि आपको अपने कोड को टेक्स्ट एडिटर के सबसे बेसिक में आसानी से पढ़ने योग्य बनाने के लिए प्रयास करना चाहिए, और यदि ऐसा नहीं है, तो इसके लिए एक अच्छा कारण होना चाहिए।
केविन

26

मैं उपयोग करना पसंद करता हूं this। विभिन्न संपादकों में कोड को पढ़ना आसान बनाता है जो स्थानीय और उसी तरह चर को रंग देते हैं। इससे कोड समीक्षा जैसी किसी चीज़ के दौरान मुद्रित पृष्ठ पर कोड पढ़ना भी आसान हो जाता है। यह अन्य डेवलपर्स के लिए चर के दायरे के रूप में एक काफी मजबूत अनुस्मारक भी है।

हालांकि, इसके खिलाफ तर्क हैं। आधुनिक आईडीई में, आप एक चर के दायरे को इसके ऊपर मँडरा कर या इसे पेड़ जैसी संरचना में देख कर पता लगा सकते हैं। आप चर के रंग और / या फ़ॉन्ट चेहरे को उनके दायरे के आधार पर भी बदल सकते हैं (यहां तक ​​कि इस तरह से, जब मुद्रित किया जाता है, तो यह स्पष्ट होता है कि चर का दायरा क्या है)।

मेरा मानना ​​है कि क्रिसएफ का अंतिम वाक्य मृत है: अपने उपयोग में सुसंगत रहें


7
"यह अन्य डेवलपर्स के लिए चर के दायरे के रूप में एक काफी मजबूत अनुस्मारक है।" - कारण मैं उपयोग करते हैं और this.कोड में देखना पसंद करते हैं । लिखने के लिए आधा सेकंड का समय लेता है और यह पता लगाने में लंबे समय तक की बचत कर सकता है कि क्या इससे पहले कि आप वास्तव में ऊंट-मामले वाले स्थानीय के बजाय पास्कल-केस की संपत्ति का उपयोग करने से पहले उस आदमी का उपयोग करें जब उसने 20 संशोधनों से पहले आखिरी मिनट में बदलाव किया था।
स्क्रव टीपी

18

एक जगह जिसका मैं लगातार उपयोग करता हूं, वह है बसने वाले और निर्माण करने वाले:

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

इसके अलावा, मुझे नहीं लगता कि इसे जोड़ना आवश्यक है। एक विधि के शरीर को पढ़ते समय, पैरामीटर और स्थानीय लोग वहीं होते हैं - और (आईडीई सहायता के बिना भी) का ट्रैक रखने के लिए काफी आसान है। इसके अलावा स्थानीय और क्षेत्र अलग-अलग प्रकृति के होते हैं (वस्तु स्थिति बनाम क्षणिक भंडारण या पैरामीटर)।

यदि चर और क्या क्षेत्र है, इसके बारे में कोई भ्रम है, तो इसका मतलब है कि एक विधि में बहुत अधिक चर / पैरामीटर हैं, बहुत लंबा और बहुत जटिल है, और इसे सरल किया जाना चाहिए।

यदि आप फ़ील्ड्स को टैग करने के लिए 'इस' का उपयोग करना चुनते हैं, तो मैं यह सुनिश्चित करने की सिफारिश करूंगा कि कन्वेंशन का हमेशा कड़ाई से पालन किया जाता है - यह वास्तव में कोई 'यह' नहीं मानना ​​शुरू करना आसान होगा, इसका अर्थ है कि यह एक स्थानीय और ब्रेक का सामान है।

संपादित करें: मैं भी इसे समान, क्लोन या किसी भी चीज़ में उपयोग कर रहा हूं, जिसमें समान वस्तु प्रकार का 'कि' पैरामीटर है:

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

8

यह बहस का विषय है।

C # को एक सादृश्य के रूप में लेते हुए क्योंकि यह जावा के समान एक समान सिंटैक्स और संरचना है, हम पाते हैं कि C # StyleCop में एक डिफ़ॉल्ट नियम है जो आपको जोड़ने पर जोर देता है this, लेकिन ReSharper का एक डिफ़ॉल्ट नियम है जो कहता है कि thisयह निरर्थक है (जो कि यह है) और हो सकता है हटा दिया।

इसलिए यदि आप एक उपकरण का उपयोग कर रहे हैं तो आप उन्हें जोड़ देंगे लेकिन यदि आप किसी अन्य का उपयोग करते हैं तो आप उन्हें हटा देंगे। यदि आप दोनों टूल का उपयोग कर रहे हैं तो आपको नियमों में से एक को चुनना और अक्षम करना होगा।

हालांकि, नियमों का क्या मतलब है कि आप अपने उपयोग में सुसंगत हैं - जो शायद सबसे महत्वपूर्ण बात है।


8

क्या इसे वर्तमान उदाहरण की विशेषताओं के लिए हमेशा पूर्व निर्धारित करना एक बुरा अभ्यास माना जाता है?

हां - कुछ के द्वारा, नहीं - दूसरों के द्वारा।

मुझे thisजावा और C # में अपने प्रोजेक्ट्स में कीवर्ड पसंद है । एक तर्क दे सकता है कि आईडीई हमेशा मापदंडों और क्षेत्रों को अलग-अलग रंग से उजागर करेगा, हालांकि हम हमेशा आईडीई में काम नहीं करते हैं - हमें बहुत सारे मर्ज करने / बदलने / नोटपैड में कुछ त्वरित बदलाव / ई-मेल में कुछ कोड स्निपेट की जांच करना होगा । यह जिस तरह से कुछ संभव संगामिति मुद्दों की समीक्षा करने के लिए, उदाहरण के लिए - आसान मुझे पहले देखो जहां उदाहरण के राज्य बदल गया है से पहचानना के लिए।


7

मुझे लगता है कि यदि आपको इसका उपयोग करने की आवश्यकता है, तो आपके पास या तो एक तरीका है जो बहुत लंबा है, या एक वर्ग जो बहुत अधिक करने की कोशिश कर रहा है, या दोनों।

तरीके कभी भी कोड की लंबी लाइनों से अधिक नहीं होने चाहिए, एक या दो स्थानीय चर का उपयोग करें, जो यह निर्धारित करता है कि क्या आसान है; यहां तक ​​कि सबसे अलग उपकरण के केवल 3 लाइनों के संदर्भ के साथ। यदि आपके तरीके बहुत लंबे हैं और आपकी कक्षाओं में बहुत अधिक जिम्मेदारियां हैं (अक्सर अर्थ कई क्षेत्रों में), तो समाधान उन्हें विभाजित करना है।

मुझे लगता है कि "यह" सिर्फ क्लुटर्स कोड है। विशेष रूप से आधुनिक आईडीई के साथ जो स्थानीय मापदंडों / स्थानीय चर / क्षेत्रों को अलग-अलग रंग देगा।


5

मुझे लगता है कि आपने इसके साथ अपने प्रश्न का उत्तर दिया :

मुझे लिखना अधिक स्वाभाविक लगता है

... यह..फू ...

से

... फू ...

चूंकि यह मुझे स्थानीय चर से उदाहरण विशेषताओं को भेद करने में मदद करता है।

यदि आप this.जावा के साथ अपने कामकाजी ज्ञान में सुधार करते हुए उपयोग करने में अधिक सहज हैं , तो हर तरह से चीज़ का उपयोग करें ( मुझे लगता है कि, एक तरह से, परिचित पायथन स्वयं जो आप संबंधित हैं )।

बात यह है कि, हालांकि लोग उपयोग करने या न करने के बारे में ठोस / प्रासंगिक तर्क देंगे this., यह अभी भी एक बहस की तरह लग रहा है, उदाहरण:

  • यह चर के उद्देश्य को स्पष्ट करता है यदि आपको स्पष्ट नहीं है कि प्रत्येक चर क्या है तो आपको कोड को फिर से लिखना चाहिए;
  • this.यदि आप अपना पूरा दिन आईडीई बनाम में खर्च करते हैं, तो मैं कोड समीक्षा करता हूं और बिना किसी सिंटैक्स हाइलाइटिंग के तुलनित्र का उपयोग करके विभिन्न संस्करणों पर भिन्नताएं बनाता हूं;
  • टाइपिंग का this.लाभ न लेना उत्पादकता के महत्वपूर्ण मिलीसेकंड बनाम मुझे कुंजी दबाकर भुगतान करना है और जोड़ना this.एक वेतन वृद्धि की तरह है: डी;
  • आदि आदि

लेकिन लब्बोलुआब यह है कि दिन के अंत में, यह अभी भी व्यक्तिगत प्राथमिकता और कार्य वातावरण के लिए फिर से शुरू होता है


5

आम तौर पर जोड़ने इस अनावश्यक है। मुझे नहीं लगता कि यह असल बुरा व्यवहार है, लेकिन के अत्यधिक उपयोग यह शायद कि मैंने देखा है सबसे जावा कोड अड्डों में असामान्य माना जाएगा।

हालाँकि मुझे कुछ विशिष्ट स्थितियों में यह मूल्यवान लगता है:

स्थानीय मापदंडों को ओवरराइड करना - कभी-कभी यह निर्दिष्ट करना आवश्यक है कि आप एक ही नाम के पैरामीटर / स्थानीय चर के बजाय एक उदाहरण चर का उपयोग करना चाहते हैं। यह कंस्ट्रक्टर्स में काफी सामान्य है, जहाँ आप चाहते हैं कि पैरामीटर नाम उदाहरण के चर के आंतरिक नाम से मेल खाए जो इसे इनिशियलाइज़ करने के लिए उपयोग किया जाता है।

class MyObject {
  int value;

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

एक ही वर्ग के अन्य उदाहरणों को संभालते समय - मेरा मानना ​​है कि यह कोड को स्पष्ट और अधिक समझने योग्य बनाता है कि आप किस वर्ग के उदाहरण का उल्लेख कर रहे हैं, जैसे

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.