क्या हमें डेवलपर की स्वायत्तता के पक्ष में कोडिंग शैलियों को प्रोत्साहित करना चाहिए, या इसे स्थिरता के पक्ष में हतोत्साहित करना चाहिए?

Question

एक डेवलपर if/elseएक-लाइन कोड स्टेटमेंट जैसे ब्लॉक लिखता है :

if (condition)
   // Do this one-line code
else
   // Do this one-line code

एक और उन सभी के लिए घुंघराले ब्रेसिज़ का उपयोग करता है:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

---

एक डेवलपर पहले किसी वस्तु को तत्काल बनाता है, फिर उसका उपयोग करता है:

HelperClass helper = new HelperClass();
helper.DoSomething();

एक और डेवलपर एक लाइन में ऑब्जेक्ट को इंस्टेंटिअेट्स और उपयोग करता है:

new HelperClass().DoSomething();

---

एक डेवलपर सरणियों के साथ अधिक आसान है, और forछोरों:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

एक और लिखते हैं:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

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

Comments

मैं वास्तव में अभी एक बहुत ही समान प्रश्न पूछने के लिए यहां आ रहा था - जब स्वचालित कोड स्वरूपण उपकरण उपलब्ध और सुविधाजनक हैं, तो क्या उन उपकरणों को चलाना (और असंगत व्यक्तिगत शैलियों को संरक्षित नहीं करना) या एक शैली को लागू करना अधिक महत्वपूर्ण है?

— शराबी

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

— स्टीफन

Answer 1

एक कोडिंग मानक दस्तावेज़ उपयोगी है। यह सबसे उपयोगी है जब यह बहुत कम है कि कोई भी बहुत परेशानी के बिना पूरी बात को याद कर सकता है और जब यह किसी को बहुत अधिक दर्द का कारण नहीं बनता है।

आप अपने संगठन में इंडेंट कोड का चयन कैसे करते हैं, या नामों को कैपिटलाइज़ करते हैं, या अपने छोरों को लागू करते हैं, या टिप्पणी करते हैं कि आपका कोड इतना सब कुछ मायने नहीं रखता है; सहायक भाग हर किसी को कोड लिखने के लिए मिल रहा है जो हर किसी के समान दिखता है।

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

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

• बैठक के अंत तक कुछ भी तय नहीं किया जाना प्रबंधक द्वारा तय किया जाएगा।
• बैठक दो घंटे के बाद समाप्त होगी, या जब कोई चिल्लाना या रोना शुरू करेगा, जो भी पहले आएगा।
• संपूर्ण मानक फिट होगा (उचित प्रकार के आकार में!) एक या दो कागज पर, यदि आवश्यक हो तो केवल दो तरफा।

किसी को अपनाने पर विचार करें | और | मानकों या तो अपने स्वयं के कोडिंग मानकों की बैठक के लिए एक शुरुआती बिंदु के रूप में, या पूरी तरह से बैठक से बचने के तरीके के रूप में।

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

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

नोट: "कोडिंग मानक" विचार प्रोग्रामिंग के लिए अद्वितीय नहीं है। "कोडिंग मानकों" का उपयोग कई क्षेत्रों में किया जाता है, कभी-कभी किसी संगठन के भीतर, पूरे उद्योग या पेशे में। कुछ उदाहरण:

• कानूनी दस्तावेज जैसे कोर्ट फाइलिंग और ट्रांसक्रिप्शंस विशिष्ट स्वरूपों का पालन करते हैं।
• स्क्रिप्ट और स्क्रीनप्ले को एक विशेष शैली में लिखा जाना चाहिए ताकि इसे गंभीरता से लिया जा सके।
• तकनीकी चित्र में अक्सर मानक रूप में एक शीर्षक ब्लॉक होना चाहिए ।
• ग्रंथ सूची प्रारूप मानकीकृत हैं।

प्रत्येक मामले में (और कई अन्य) एक सक्षम चिकित्सक आसानी से "कोड" को समझ सकता है जो अपेक्षित मानक को पूरा नहीं करता है। इतने सारे उद्योग दस्तावेजों के लिए विस्तृत आवश्यकताओं को लिखने में क्यों लगे रहते हैं, जिन्हें संकलक द्वारा पार्स करने की आवश्यकता नहीं होती है? क्योंकि स्टाइल मायने रखता है । एक मानक शैली में जानकारी पेश करने से पाठक पूरी तरह से सामग्री पर ध्यान केंद्रित कर सकता है, तेजी से पढ़ने और समझने में सहायता करता है, और त्रुटियों को कम करता है।

Comments

यदि आप अपने पोस्ट में लाइनिंग टूल्स का उपयोग जोड़ते हैं, तो मैं मेरा और +1 आपका :) हटा दूंगा

— डेमियन ब्रेख्त

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

— कालेब

अच्छा तो ठीक है। +1 फिर भी :)

— डेमियन ब्रेख्त

और आपको भी!

— कालेब

+1 के लिए "... तत्काल स्थानांतरण ..." जैसा कि मेरे अनुभव में इस तरह का व्यवहार सोसोपाथ और / या संकीर्णतावादी प्रवृत्तियों के अनुरूप है, सॉफ्टवेयर विकास टीमों के साथ असंगत है।

— मटनज़

Answer 2

स्टाइल मायने नहीं रखता।

वहाँ, मैंने कहा।

30 वर्षों के बाद, और सैकड़ों ग्राहक साइटें, और उन वर्षों में टीम के सदस्यों से (अनुमान) 500 (या अधिक) से कोड, मैंने पाया है कि शैली सिर्फ मायने नहीं रखती है।

यह काम करने के लिए, पहले जाओ।

संसाधनों का एक इष्टतम मात्रा (यानी, सही डेटा संरचना, सही एल्गोरिदम) का उपयोग करने के लिए इसे प्राप्त करें।

"स्टाइल" पर उपद्रव के बाद बाकी सब कुछ हल हो गया है। केवल उपकरणों के साथ "शैली" का उपद्रव, कभी भी मैन्युअल रूप से नहीं।

Comments

तथास्तु! कोडिंग मानकों को वास्तविक लाभों के संदर्भ में उचित ठहराया जाना चाहिए और स्थिरता वास्तविक लाभ नहीं है, बल्कि एक लक्जरी है।

— JohnFx

लेकिन शैली के बारे में शायद ही कभी शैली होती है। यह सामान्य त्रुटियों से बचने के बारे में है।

— मार्टिन यॉर्क

लेकिन यह '==' के बजाय '=' से बचने में मदद करता है (स्थिति के अंदर असाइनमेंट का उपयोग न करें)। यह मदद करता है if (t) { x;y;}बजाय से बचने if (t) x;y;(हमेशा अगर के बाद '{}' का उपयोग)। कांस्ट सही कोड को प्राथमिकता दें (यह लिखे जाने के बाद कोड में कांस्ट शुद्धता को जोड़ना बहुत कठिन है। std का उपयोग करें: cout / std :: cin not fprintf / scanf the पूर्व में त्रुटियों की संभावना अधिक होती है। सरणियों के बजाय वेक्टर का उपयोग करें। (अतिप्रवाह रोकने में मदद करने के लिए)।

— मार्टिन यॉर्क

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

— कालेब

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

— शराबी

Answer 3

कोडिंग स्टाइल हैं और कोडिंग स्मेल हैं। यह एक बार मुझे नहीं मिला था:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

मेरे पिछले नियोक्ता ने बहुतायत से if()बिना ब्रेसिज़ का उपयोग करने के लिए कड़ाई से मना किया है। यह माना जाता था कि "इसे फिर से करें और आपको निकाल दिया जाए" प्रकार की गलती। स्वीकृत निर्माण थे

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

यह मेरे द्वारा दिखाए गए जैसे ही एक त्रुटि के कारण हुआ, जिसने पोर्टल के मुख्य पृष्ठ को एक स्टॉप पर लाने के लिए कुछ घंटों का समय लिया।

ऐसी चीजें हैं जिन्हें आपको हमेशा करना चाहिए। जैसे switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

इस बीच, टाइपिंग:

     case 1:
         something();
     case 2:
         something();
     break;

एक के caseसाथ बंद किए बिना //fallthroughबग माना जाता है।

आम तौर पर, कोडिंग मानक होता है जो दिशानिर्देश है जिसे अनदेखा किया जा सकता है, रचनात्मक रूप से व्याख्या या दी गई आवश्यकताओं के लिए संशोधित किया जा सकता है। और "गंध" पर अनुभाग है और इसे सख्ती से पालन करना है।

Answer 4

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

यह डिजाइन मुझे अन्य डेवलपर्स के लिए कार्यान्वयन विवरण को सौंपने की भी अनुमति देता है। इस तरह वे पूरे सिस्टम डिज़ाइन को बनाने के बजाय रिक्त स्थान को भर रहे हैं।

एक समग्र डिजाइन की कमी प्रणाली की विसंगतियां पैदा करती है। बुनियादी पुनरावृत्तियों और लूपिंग निर्माणों की आलोचना प्रणाली के डिजाइन में सुधार करने के लिए बहुत कम करती है। इस तरह की समस्याओं को बेहतर तरीके से हैंड्स ऑफ एप्रोच, स्टाइलकॉप से हल किया जाता है ।

क्या आप अपने समग्र सिस्टम डिज़ाइन का अपेक्षाकृत सरल आरेख बना सकते हैं? नए टीम डेवलपर में शामिल तत्वों / संस्थाओं का वर्णन करने वाला एक डिज़ाइन। यदि आप नहीं कर सकते हैं, या यह अत्यधिक शामिल है तो डिजाइन की कमी है।

Answer 5

IMHO यह निर्भर करता है ...

आपके पहले दो उदाहरण मेरे लिए सिर्फ व्यक्तिगत स्वाद की बात नहीं हैं।

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(कोष्ठक के बिना) = अधिक बग-प्रवण, यदि बाद में अधिक कोड जोड़ा गया है:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

और यह डिबग करने के लिए कम सुविधाजनक है:

new HelperClass().DoSomething(GetSomeData()); // etc.

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

आपके तीसरे उदाहरण के लिए (बनाम फॉरचेक के लिए), मैं इसे स्वाद के मामले के रूप में देखता हूं।

Answer 6

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

Answer 7

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

Answer 8

एक उद्योग मानक अस्तर उपकरण का उपयोग करें (जाहिरा तौर पर C # के लिए FxCop )। हालांकि यह अंत नहीं, हो सकता है-सब, स्थिरता है बड़ी परियोजनाओं उन पर काम कर रहे लोगों की एक संख्या है कि में महत्वपूर्ण।

यदि आप केवल अपनी परियोजना या छोटी टीम पर काम कर रहे हैं, तो कई तर्क देंगे कि यह ओवरकिल है। मुझे विश्वास है कि अन्यथा (मैं अपने व्यक्तिगत एकल-डेवलपर परियोजनाओं में भी अजगर के लिए PEP8 का उपयोग करता हूं )।

हालाँकि, आपके द्वारा दिए गए अधिकांश उदाहरण, संभवतः सबसे अधिक लिनिंग टूल द्वारा पकड़े नहीं जाएंगे क्योंकि वे केवल मायने नहीं रखते हैं।

Answer 9

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

Answer 10

यह दोनों का मिश्रण है। सिर्फ इसलिए कि यह एक मानक है यह पठनीय और बनाए रखने योग्य नहीं बनाता है। यदि अभी तक कोई इंस्टाल्ड स्टैण्डर्ड नहीं है, या इसमें दोषपूर्ण और अपठनीय पहलू हैं, तो संशोधन उचित है।

Answer 11

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

यह प्रोग्रामर को कुछ स्टाइल गाइडेंस देने में मददगार है। प्रोग्रामर को काम पर रखने से पहले यह किया जा सकता है / किया जाना चाहिए, खासकर अगर वे पर्यावरण के सापेक्ष शुरुआती हैं, या स्वयं प्रोग्रामिंग करने के लिए। मार्गदर्शन को देखते हुए, कुछ प्रोग्रामर बहुत स्टाइल के प्रति जागरूक होंगे, अन्य कम। परियोजना की शुरुआत में दिए गए मार्गदर्शन से प्रोग्रामरों के पहले समूह को मदद मिलेगी, जिससे समग्र कार्य आसान हो जाएगा। यह दूसरे समूह के लिए बहुत कम कर सकता है, जो (उम्मीद है) रचनात्मकता में बनाते हैं, उनके अनुरूप क्या होगा।

Answer 12

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

if() {}
else() {}

या और भी:

if() {} else () {}

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

Object.method();
Object.method2();

तब आपने ऑब्जेक्ट कॉन्स्टेक्टर विधि को दो बार कॉल किया जब इसे ऑब्जेक्ट को पूरी तरह से टालने से बचा जा सकता था।

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

Answer 13

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

टीम के अन्य सदस्यों के कोड के साथ काम करने के बाद, कभी-कभी कुछ महीनों के लिए कम, यह अनिवार्य रूप से एक इन-लाइन काम करना शुरू कर देता है git blame । 10+ वर्षों से मेरी कंपनी में होने के बाद, मैं शायद आपको 80% + सटीकता के साथ बता सकता हूं जिन्होंने हमारे 500k लाइनों के कोड में कहीं भी किसी भी वर्ग को लिखा है, बस इसे देखकर।

जब आप "रैंप टाइम" का एक छोटा सा हिस्सा होते हैं, जब आप उस कोड को देखना शुरू करते हैं जो एक ऐसी शैली का उपयोग करता है जिससे आप सहमत नहीं हैं, तो आप वास्तव में उस समय क्या कर रहे हैं "ओह, यह कह रहा है कि यह जॉन डो के कोड जैसा दिखता है (क्योंकि वह स्टाइल एक्स का उपयोग करता है लेकिन स्टाइल वाई का नहीं, आदि) "। और वह अपने साथ संदर्भ का एक पूरा ढेर लेकर आता है। पहले सन्निकटन के लिए, आप जानते हैं कि जॉन के कोड से क्या उम्मीद की जाती है - कोडबेस के अन्य हिस्सों को वह अच्छी तरह से समझता है और वह क्या करता है, वह एसक्यूएल गुरु या जीयूआई नौसिखिया आदि नहीं है, आदि।

एक फॉर्मेटर के माध्यम से हर किसी के कोड को चलाना अनिवार्य रूप से इस जानकारी को छीन लेता है, इसे एक के पीछे छिपा देता है git blame, जिसे आप चलाने के लिए परेशान नहीं कर सकते हैं।

Answer 14

यह वास्तव में संगठन के प्रकार पर बहुत कुछ निर्भर करता है।

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

यूनिवर्सल मानक सभी को B + खिलाड़ी बनाने के लिए सर्वश्रेष्ठ हैं। इससे आपके सुपरहीरो खिंच जाएंगे। लेकिन अगर आप B + के लिए औसतन एक A और आधा दर्जन B खिलाड़ी और आधा दर्जन C खिलाड़ी चाहते हैं, तो आप लगातार मानक चाहते हैं। इस उदाहरण में, आप चाहते हैं कि सभी लोग समान कार्य करें ताकि एक A खिलाड़ी जितनी जल्दी हो सके सभी के कोड से चल सके।

आप में से कई लोग कहते हैं, "लेकिन रुको, बी और सी के खिलाड़ियों के साथ दूर क्यों नहीं?"

वास्तविकता यह है कि कई सुपरहीरो नहीं हैं। हालांकि यह Google पर उन्हें खोजने और उनका पोषण करने के लिए भुगतान कर सकता है, मा बेल के लिए एक नई बिलिंग प्रणाली में डालना बाद की टीम के साथ अधिक लागत प्रभावी हो सकता है। (और यदि आपके पास वास्तव में सुपरहीरो हैं, तो उनमें से 4 या 5 एक दर्जन जूनियर्स से दोगुने महंगे होंगे)