मुझे हमारे कोडिंग मानकों में से एक से नफरत है और यह मुझे पागल कर देता है, इसे कैसे संसाधित किया जाए? [बन्द है]


18

अस्वीकरण : शीर्षक के रूप में अतिरंजित नहीं है, लेकिन यह अभी भी मुझे असहज बनाता है। मैं बस ईमानदारी से व्यक्त करने जा रहा हूं, इसलिए इसे नमक के दाने के साथ लें। बस बहाना है कि मैं उस कोडिंग मानक के बारे में बात कर रहा हूं जिसे आप के साथ काम करना पसंद नहीं है।

संपादित करें : यह तथ्य कि मुझे यह पसंद नहीं है, इसका मतलब यह नहीं है कि मैं इसका उपयोग नहीं करता या इसे लागू नहीं करता।


मैंने इस सवाल को पूछने का फैसला किया कि कैसे आप एक मानक को प्राप्त करना पसंद करते हैं, न कि बेहतर तर्क देने के तरीके पर मदद प्राप्त करने के लिए कि इसे कैसे बदला जा सकता है (हालांकि इस अंतिम भाग के बारे में कोई भी टिप्पणी की सराहना की जाती है)। इसके अलावा, मैं एक बड़ी कंपनी में काम करता हूं और कुछ ऐसा बदलाव आया है जो इतने लंबे समय तक रहता है और इतना कम मायने नहीं रखता है।

मानक उद्घाटन-घुंघराले-ब्रेस-ऑन-समर्पित-लाइन मानक है:

somefunction()
{
    //...
}

इसके बजाय * स्पष्ट रूप से बेहतर * (मजाक / कुंठित स्वर पर ध्यान दें):

somefunction() {
    //...
}

मानक के खिलाफ मेरे व्यक्तिगत तर्क:

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

उनके तर्क (और आंतरिक रूप से उनका प्रतिशोध लेने का मेरा तरीका):

  • पढ़ने में आसान क्योंकि आप देख सकते हैं कि ब्लॉक कहाँ से शुरू होते हैं और तुरंत खत्म होते हैं : मैं यह नहीं समझ सकता, क्या अच्छा है अगर आप यह नहीं जानते कि यह किसके स्वामित्व में है, इसलिए आपको पीछे की ओर पढ़ना होगा।
  • मैंने इसे Microsoft IDE में उपयोग किया और मुझे यह पसंद आया : उह ... ठीक है?
  • यह मानक में है : * cringes *

क्या मैं केवल एक विशिष्ट मानक के खिलाफ एक राय के साथ संघर्ष कर रहा हूँ ?, आप इस पर कैसे मिल गए हैं ?, इस विशेष मानक क्या होना चाहिए (सिर्फ मनोरंजन के लिए) पर आपकी क्या राय है?


6
कब तक आप "नफरत" मानक का उपयोग करते हैं? और क्या आप "समानांतर" में अन्य मानकों का उपयोग करते हैं? मेरा मतलब है, क्या यह सिर्फ इसकी आदत हो सकती है? मानना ​​पड़ेगा कि मैं एक ही मानक से घृणा करता था, लेकिन लगभग एक साल के बाद विशेष रूप से इस तरह से लिखने से यह नफरत पूरी तरह से दूर हो गई है
gnat

54
आप फ़ंक्शन घोषणा के अंत और घुंघराले ब्रैकेट के बीच स्पष्ट रूप से आवश्यक व्हाट्सएप को छोड़ रहे हैं ! आपको जलना ही चाहिए!
पाप

5
इसके साथ जियो। यह वास्तव में, वास्तव में मामूली समस्या है। खुश रहिए कि वही आपको परेशान कर रहा है। यदि आप भाषा बदलते हैं तो आपको नई शैली में समायोजित करने में भी सक्षम होना चाहिए। इसलिए इसके साथ कुछ हफ्तों तक काम करना इस भावना को ठीक करना चाहिए कि यह "गलत" है।
Schlingel

8
Used by people who come from a Microsoft IDE backgroundयह एक Microsoft चीज नहीं है, उदाहरण के लिए लिनक्स कर्नेल और K & R एक ही शैली का उपयोग करते हैं।
लुकास

5
यदि आप अपनी ऊर्जा का सभी खर्च तुच्छ के बारे में निकाल रहे हैं, तो आप उन चीजों के लिए कोई कसर नहीं छोड़ेंगे जो वास्तव में मायने रखती हैं।
ब्लरफाल

जवाबों:


47

यदि आप इस पर उतरना चाहते हैं - तोरवाल्ड्स का एक उद्धरण था:

खराब प्रोग्रामर कोड के बारे में चिंता करते हैं। अच्छे प्रोग्रामर डेटा संरचनाओं और उनके संबंधों के बारे में चिंता करते हैं।

अब विचार करें, यह उन प्रोग्रामरों को कहां रखता है जो अपने कोड मानक द्वारा लागू की गई ब्रेकिंग स्टाइल जैसी मामूली चीज के बारे में चिंता करते हैं? क्या आपका कोडबेस अन्यथा इतना पुराना है कि इसके बारे में बहस करने के लिए केवल समय के लायक ब्रेसिंग ही एकमात्र मुद्दा है?


2
मैं पूरी तरह सहमत हूं। यदि आपने अन्य सभी समस्याओं को हल कर लिया है और यह तय करना है कि क्यूरलस को कहाँ रखा जाए, तो यह सबसे महत्वपूर्ण बात है, आप वहां मौजूद हर दूसरे सॉफ्टवेयर प्रोजेक्ट से बेहतर कर रहे हैं।

4
क्या आपका कोडबेस अन्यथा इतना पुराना है कि इसके बारे में बहस करने के लिए केवल समय के लायक ब्रेसिंग ही एकमात्र मुद्दा है? - यह एक आलंकारिक प्रश्न होगा - ऐसा कोडबेस इतिहास में कभी मौजूद नहीं है!
मैटडवेई

12
मैं यह जोड़ना चाहूंगा कि यदि आप "गलत तरीके से" वायर्ड.com
Giles Roberts

ऐसा इसलिए है क्योंकि वह इस तथ्य पर टिप्पणी कर रहे थे कि आप एक परियोजना में जा रहे हैं, आप परियोजना की शैली मार्गदर्शिका का सम्मान करते हैं और इसे बदलने के लिए प्रस्ताव प्रस्तुत करते हैं ... अन्यथा उनकी शैली से चिपके रहते हैं!
रुडोल्फ ओलह

1
@GilesRoberts: यदि आप मैसेज को "गलत तरीके से" करते हैं, तो लिनुस पागल हो जाता है, क्योंकि यह स्थापित समीक्षा प्रक्रिया के साथ काम नहीं करता है। एक जो 20 वर्षों के लिए परियोजना के लिए अच्छा काम करता है और जिसमें सैकड़ों लोग शामिल हैं। कुछ प्रक्रिया नियम कोड स्वरूपण की तुलना में बहुत अधिक महत्वपूर्ण हैं।
Jan Hudec

66

कुछ लोग इसे आपके तरीके से पसंद करते हैं और अन्य लोग नहीं करते हैं। किसी भी तरह से किसी को नाराज किया जा रहा है। इस समय आपकी बारी है। इसे चूसो और काम पर लग जाओ।


5
मुझे लगता है कि वह पूछ रहा है कि उसे कैसे प्राप्त करना चाहिए। जो वास्तव में एक बहुत अलग सवाल है।
ज़ाचरी येट्स

18
मानक का पालन नहीं करना एक बदतर समस्या पैदा करता है, और सभी को परेशान करता है । "इसे चूसो" वास्तव में!
फ्रैंक शीयर

2
मैं सहमत हूँ। आपको बस इससे निपटना है।
कोडी

3
ईमानदारी से, यह मुझे भी निराश करेगा, लेकिन "इसे चूसना" सही उत्तर है, दुर्भाग्य से।
सुल्तान

27

क्या टीम का मानक दस्तावेज है? यदि यह है, तो स्टाइल गाइड में कोई कारण हैं? ईमानदारी से, मुझे इसे कई बार चूसना और वास्तविक काम करना था। इससे भी बदतर समस्याएं हैं, लेकिन मैं आपको महसूस करता हूं - यह अभी भी रैंक किया गया है (मैं शैली पर आपके साथ सहमत हूं, वैसे)।

इसके माध्यम से मुझे क्या मदद मिली:

  1. एहसास हुआ कि एकल शैली के वास्तविक लाभ हैं (कोई फर्क नहीं पड़ता कि यह क्या है)। या कम से कम लोगों का एक समूह ऐसा सोचता है
  2. वास्तव में आपने अभी क्या किया है, यह लिखें कि यह गलत क्यों लगता है, इसलिए आप भविष्य में तर्क को अच्छी तरह से प्रस्तुत कर सकते हैं।
  3. भगवान के लिए एक स्टाइलिंग टूल का उपयोग करें , यह आपकी पवित्रता को बचाएगा। Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , आदि ... यहां तक कि दृश्य स्टूडियो यह तुम्हारे लिए क्या करेंगे
  4. इस परियोजना पर किक करें और अगले के लिए तैयार रहें जब आप मानकों को निर्धारित कर सकते हैं।

7
+1 (3), बोनस अंक यदि आप इसे SCM के लिए पोस्ट-पुल / प्री-पुश हुक के रूप में सेट करते हैं।
मार्टिन ग्रीन

1
स्टाइलिंग टूल इस समस्या को दूर करते हैं और लोगों को अपना पैसा लगाते हैं जहां उनका मुंह है। यदि आप वास्तव में एक विशेष तरीके से घुंघराले को ढीला करते हैं , तो आप अपने स्टाइलिंग कॉन्फ़िगरेशन को बदलने के लिए इसे अपने लिए गर्म और आरामदायक बनाते हैं। अन्यथा, अपना मुंह बंद करें कोडिंग प्राप्त कर सकते हैं।
कैलफूल

16

एक सम्मेलन की श्रेष्ठता दूसरे पर * स्पष्ट रूप से मनमानी * है

आपके द्वारा सामना की जाने वाली पठनीयता के मुद्दे, या आपकी टीम के साथी आपके मानक का सामना करेंगे, केवल परिवर्तन के लिए एक मनोवैज्ञानिक प्रतिरोध है।

उद्देश्य पठनीयता तर्क पूरे कोड आधार पर * स्थिरता * के पक्ष में है ।


"केवल" एक मनोवैज्ञानिक प्रतिरोध को बदलने के लिए? परिवर्तन के लिए मनोवैज्ञानिक प्रतिरोध काफी बड़ा हो सकता है।
जाइल्स रॉबर्ट्स

8

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

जब मैं कोडिंग के लिए काफी नया था (मेरे करियर में पांच साल का कहना है) तो मेरे अपने मानक गुस्से में थे कि क्या मल्टीवर्ड पहचानकर्ता होना चाहिए WrittenLikeThisया था written_like_this। मैं यह भी नहीं कहूंगा कि मैंने किसको lked किया, लेकिन मुद्दा यह है कि कुछ समय बाद मैंने पक्ष बदल दिए और कुछ और समय के बाद मैंने किसी भी तरह से ध्यान नहीं दिया।


हां, मैं like_this और likeThis के बीच फटा हुआ हूं। मैं हाल ही में सभी-लोअरकेस शैली की ओर झुक रहा हूं, यह पढ़ने के लिए केवल स्पष्ट है।
doug65536

1
बेशक, अब मैं कुछ परियोजनाओं में इस तरह से फंस गया हूं। ओह ठीक है, चीजों की भव्य योजना में नामकरण परंपराएं बहुत महत्वपूर्ण नहीं हैं।
doug65536

1
बिल्कुल सही। यह मामूली बात नहीं है कि उद्घाटन ब्रेस किस लाइन पर है। यह थोड़ी सी भी बात नहीं है कि क्या आप मल्टीवार्डआईडेंटिफायर या मल्टी_ओर्ड_फीडफायर्स लिखते हैं। आपकी कंपनी जो भी मानक का उपयोग करती है, उसके साथ जाएं, और कुछ महीनों में आपको यह याद रखना मुश्किल होगा कि आप कभी भी इसे दूसरे तरीके से करना चाहते थे।
कार्सन 63000

8

घुंघराले ब्रेस के साथ आपके द्वारा वर्णित मानक अंतर काफी हद तक मनमाना है। दोनों तरीके समान रूप से अच्छे हैं और किसी कंपनी के लिए, जब तक हर कोई इसे करता है तब तक यह सभी अच्छे होते हैं।

जिस "स्पष्ट रूप से श्रेष्ठ" के बारे में आप बात कर रहे हैं वह उस प्रकार का श्रेष्ठ है जिसके बारे में लोग बात करते हैं जब वे "वे उपयोग किए जाते हैं" के बारे में बात करते हैं।

आप जल्द ही और एक या एक साल में इसकी आदत डाल लेंगे, दूसरा तरीका "स्पष्ट रूप से बेहतर" होगा।

तो संक्षेप में: इसके साथ सौदा।


एक स्पष्ट रूप से बेहतर जवाब
मावग का कहना है कि मोनिका

5

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

अंततः, न तो सही है और न ही गलत है।

स्टाइल गाइड और कोडिंग मानक कई कारणों से मौजूद हैं - और एक प्रमुख पहलू लेआउट की एकरूपता सुनिश्चित करना है, जिसका उद्देश्य स्पष्ट त्रुटियों की संख्या को कम करना और स्थिरता में सुधार करना है।

क्या मैं केवल वही हूं जो एक विशिष्ट मानक के खिलाफ एक राय के साथ संघर्ष करता है?

संक्षिप्त उत्तर है "नहीं" आप केवल एक ही नहीं हैं। लेकिन चिंता करने वाली और भी महत्वपूर्ण बातें हैं। यहां तक ​​कि मानकों में से एक के लिए इनपुट है, वहाँ हमेशा समझौता होगा - कुछ पहलुओं का गवाह है जिन्होंने इसे C99 और C12 में बनाया है जो मेरे लिए कोई मतलब नहीं है।

यहां तक ​​कि MISRA-C (जिस पर मेरा सीधा प्रभाव है) में वे आइटम हैं जो व्यक्तिगत रूप से मेरे साथ सहमत नहीं हैं - लेकिन मैं समझ सकता हूं कि अन्य लोग इसके लिए औचित्य क्यों महसूस करते हैं।

आपने इन पर कैसे काबू पाया है?

और इसमें उत्तर निहित है - इस पर ध्यान केंद्रित करने के बजाय कि आप व्यक्तिगत रूप से इसे पसंद क्यों नहीं करते हैं, यह समझने और समझने की कोशिश करें कि जिस व्यक्ति / लोग ने इसे स्वीकार किया, उसने ऐसा क्यों किया।

नियमों को आम तौर पर पेश किया जाता है (पिछली स्थिति को दूर करने के लिए घोड़े के बाद एक स्थिर स्थिर दरवाजे में)। और अगर नियम अभी भी बकवास है, तो मानक मालिक से बात करें और उन्हें "शिक्षित" करने का प्रयास करें।


4

मुझे लगता है कि आपको बस इसके साथ जुड़ने की जरूरत है। मैं अपनी राय के साथ आपके नोटों को संबोधित करने की कोशिश करूंगा:

  • ब्लोट्स कोड

    कोड की एक अतिरिक्त पंक्ति तब तक ब्लोटिंग कोड नहीं है, जब तक कि आप एकल वर्ग में 100 के तरीके नहीं लिख रहे हैं, जो सैकड़ों अतिरिक्त लाइनें जोड़ देगा। तब फिर से अगर आपके पास एकल वर्ग में सैकड़ों विधियां हैं तो आपको पूरी तरह से एक और समस्या है।

  • टाइप करने के लिए कठिन

    मैं इस बारे में आपसे अधिक असहमत नहीं हो सकता, आपको अगली पंक्ति में जाने के लिए रिटर्न कुंजी को वैसे भी दबाना होगा। इसके बारे में लिखना कठिन है?

  • पढ़ने में कठिन

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

  • उन लोगों द्वारा उपयोग किया जाता है जो एक MS IDE पृष्ठभूमि से आते हैं

    उह ..... ठीक?

सारांश में ऐसा लगता है कि आप किसी .net डेवलपर के रूप में किसी अन्य प्रकार के डेवलपर के विपरीत होने के बारे में नाइटपैकिंग कर रहे हैं जैसे कि उसका अवर क्योंकि वे एक आईडीई का उपयोग करते थे जो इस मानक को चूकता है।


1
-1 मैं सभी बिंदुओं पर सहमत हूं, लेकिन मुझे नहीं लगता कि विभिन्न बिंदुओं में से प्रत्येक पर कोई राय विशेष रूप से उपयोगी है।
कालेब

4

क्या मैं केवल वही हूं जो एक विशिष्ट मानक के खिलाफ एक राय के साथ संघर्ष करता है?

बिलकूल नही। कोडिंग मानकों को निर्धारित करने के लिए बैठकें भयानक हैं! वे घंटों तक खींचते हैं और प्रतिभागियों को व्यक्तिगत रूप से अपने पसंदीदा (और हमेशा की तरह गलत, मेरा छोड़कर) में निवेश किया जाता है मानक में निहित idiosyncrasies। अंत तक, कोई भी परिणाम से खुश नहीं है। यदि कोडिंग मानकों की बैठक से कुछ भी खराब हो सकता है, तो यह कई महीनों में औपचारिक कोड की समीक्षा बैठकें हैं जो मानक के निर्धारण का पालन करती हैं: कुछ लोग मानक को अपनाने की कोशिश करते हैं, जबकि अन्य (जानबूझकर या नहीं) इसे अनदेखा करते हैं, और आप प्राप्त करते हैं प्रति घंटे की प्रतिक्रिया: लाइन्स 132, 142, 145, 181, 195, और 221 की सिल्लीफाइलकंट्रैक्टर.कप पर आप शुरुआती ब्रेस उसी लाइन पर डालते हैं जब कोडिंग मानक स्पष्ट रूप से कहता है कि यह निम्न पंक्ति पर होना चाहिए !

आपने इन पर कैसे काबू पाया है?

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

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


"भाषा मानकीकरण के प्रयास में शामिल हों ... भाषा के मानकीकरण के प्रयास को जितनी जल्दी हो सके बंद करने का अच्छा अर्थ है" - norvig.com/21-days.html
बेनी चेर्नियाव्स्की-पास्किन

3

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

इसे खुद पर हंसने के अवसर के रूप में लें, वे वास्तव में व्यवसाय में अक्सर पर्याप्त नहीं आते हैं।


2

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

हालाँकि आप जिस मानक से सहमत नहीं हैं, उससे निपटने के बारे में सवाल अधिक जवाबदेह है। मुझे लगता है कि इसका उत्तर यह है कि जहां स्टाइल दिशानिर्देश मौजूद हैं और वे सहमत हैं और उनका उपयोग किया गया है तो उत्तर सिर्फ मुस्कराहट, सहन करना और बस उससे निपटना है। विचार करें कि स्थिरता होना अधिक महत्वपूर्ण है। यदि दिशानिर्देश गलत है या गलत है तो परिवर्तन के लिए एक तर्क हो सकता है लेकिन यह शैलीगत है इसलिए व्यक्तिगत पसंद के अलावा कोई तर्क नहीं है।

मैं मूल रूप से आपके द्वारा उल्लिखित एक जावा बैकग्राउंड से आया था। मैं तब और अधिक C ++ और C # में चला गया, जहाँ आपके द्वारा नफरत की गई शैली का उपयोग किया जाता है। लेकिन इसका कोई सही या गलत जवाब नहीं है। क्या अधिक महत्वपूर्ण है एक मानक सभी द्वारा पीछा किया जा रहा है। यदि एक कोडिंग मानक इस तरह से शैलीगत है और स्पष्ट रूप से गलत नहीं है, तो यह तर्क देने की कोशिश करना टीम में सिर्फ घर्षण पैदा करेगा।


1
जैसा कि प्रश्न में कहा गया है, प्रश्न वास्तव में विशिष्ट मानक के बारे में नहीं है, इसलिए आपका पहला पैराग्राफ जर्मे नहीं है।
कालेब

2

हुक में एक फॉर्मैटर + चेक एक अच्छी शुरुआत है। लेकिन यह पर्याप्त नहीं है, क्योंकि आप जो लिखते हैं वह उतना महत्वपूर्ण नहीं है जितना कि आप पूरे दिन घूरते हैं। कुछ स्थितियों में, Emacs 'Glasses मोड का दृष्टिकोण - उनकी शैली में फाइलें रखना लेकिन आपकी शैली के करीब प्रदर्शित करना - आकर्षक है।

इसके साथ मेरा अनुभव - वास्तव में उस मुद्दे का सामना करना जिसके लिए यह लिखा गया था, CamelCapsबनाम underscore_separated- यह था कि यह जल्दी से सहायक से अधिक कष्टप्रद हो गया, लेकिन कुछ हफ़्ते के लिए इसने कंपनी की शैली को स्वीकार करते हुए मेरे संक्रमण को धीमा कर दिया, साथ ही साथ एक आउटलेट भी प्रदान किया। अपने गुस्से को दूर करने के लिए ("आह मैं इसे नफरत करता हूं, मुझे फिर से सेटिंग्स समायोजित करने दें ... वहां, कम से कम मैंने कुछ किया ";;)

वैसे भी, चश्मा मोड ब्रेस प्लेसमेंट को नहीं संभालता है, आप संभवतः Emacs का उपयोग नहीं करते हैं, और अपने संपादक में विशेष रूप से कोड नहीं पढ़ते हैं :-(
लेकिन अंतिम बिंदु भी एक अवसर है - यदि आप कोड को अधिकांश समय पढ़ते हैं एक अलग टूल, आप हैक कर सकते हैं कि राउंड-ट्रिप रिफॉर्मेटिंग शोर के बारे में चिंता किए बिना शैलियों को परिवर्तित करने के लिए - क्योंकि यह केवल-पढ़ने के लिए है! विशेष रूप से, यदि आप कुछ वेब इंटरफ़ेस (ओं) में कोड पढ़ते हैं, तो Greasemonkey का उपयोग करें।

यहां हल्के शमन के कुछ आसान उपाय दिए गए हैं:

  • खोई हुई स्क्रीन लाइनों को पुनः प्राप्त करने के लिए एक व्यापक लेकिन इतना उच्च फ़ॉन्ट नहीं चुनें।

    • पूर्ण-स्क्रीन का उपयोग करें, यदि उपलब्ध हो।
  • सूक्ष्म रंग (और छोटे फ़ॉन्ट?) में हाइलाइट किए जाने के लिए ब्रेसिज़ सेट करें, जिससे उन्हें बाकी कोड की तुलना में कम दिखाई दे। पढ़ने, जासूसी के लिए इंडेंटेशन पर्याप्त होना चाहिए। {लाइनों से खाली जगह के साथ ...

  • सुनिश्चित करें कि आपके संपादक जब आप खत्म }हो रहे हैं, तो ब्रेसिंग पर प्रकाश डाला जा सकता है - जब आपकी आंखें गलत जगह पर जाती हैं, तो थोड़ी मदद कर सकती हैं।

  • "टाइप करने के लिए कठिन": एक वास्तविक संपादक प्राप्त करें, जब आप दबाते हैं तो एक नई लाइन खोलने के लिए इसे कॉन्फ़िगर करें {


0

इसके साथ जियो।

यह स्पष्ट रूप से सौंदर्य प्रसाधन है और एक डेवलपर के रूप में कोड की गुणवत्ता या आपकी उत्पादकता के बारे में कुछ भी नहीं बदलता है। एक तर्क शुरू करने के लायक कुछ भी नहीं है।

उस तरह के कोडिंग मानक के लिए, मैं किसी भी दिन किसी भी विशेष (यहां तक ​​कि अच्छी तरह से तर्कपूर्ण) "धार्मिक" दृष्टिकोण पर कोड आधार और पठनीयता में निरंतरता चुनूंगा।

एक महत्वपूर्ण समस्या के बारे में टीम के सदस्यों के बहुमत के लोकतांत्रिक निर्णय के रूप में इसे सोचने से आपको इस पर काबू पाने में मदद मिल सकती है।


-2

यह मानक है:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

अधिकांश लोगों का कहना है कि "इसका मानक" "पांच बंदर" सिद्धांत का पालन कर रहे हैं।


1
क्या आप कृपया बता सकते हैं कि प्रश्न का उत्तर कैसे दिया जाता है?
कुटकी

क्या यह स्पष्ट नहीं है?
मावग का कहना है कि मोनिका

-5

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


2
-1 सवाल का विषय यह है कि मैं इस पर कैसे पहुँच सकता हूँ? , लेकिन आपकी सलाह इसे खत्म करने की कोशिश नहीं करती है, बस इसे अपने तरीके से करते रहें। यह मददगार नहीं लगता। यह भी बहुत व्यावहारिक नहीं है - एक प्रीपेट्रिन्टर का उपयोग करने से संपार्श्विक क्षति की संभावना पैदा होती है, अर्थात आपके पसंदीदा प्रारूप में परिवर्तित होने और फिर से वापस आने के बाद, कई लाइनें बिल्कुल समान नहीं हो सकती हैं, भले ही उनका मतलब एक ही बात हो। यह विभिन्न संस्करणों के माध्यम से देख रहे लोगों के लिए बहुत परेशानी पैदा करता है जो यह पता लगाने की कोशिश कर रहे हैं कि वास्तव में क्या बदल गया है।
कालेब

@ कालेब - यह संभव हो सकता है कि प्रेटीप्रिन्टर का उपयोग करने का आपका अनुभव अलग हो। हम Atristic स्टाइल का उपयोग कर रहे हैं और किसी को भी इसके बारे में कोई शिकायत नहीं है।
मनोज आर।

9
किसी भी गंभीर सॉफ्टवेयर विकास एक स्रोत नियंत्रण प्रणाली का उपयोग करने जा रहा है। उन अंतरों का परिचय देना जो महत्वपूर्ण नहीं हैं, समस्याओं का कारण बनेंगे और लोगों को अंतर देखने में परेशान करेंगे - या इससे भी बदतर, चेक-इन संघर्षों का कारण बनेंगे।
डग ६५५३६
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.