मुझे विश्वास नहीं है कि एक देव टीम के पास शैली के दिशानिर्देश होना चाहिए, उन्हें सामान्य नियम के रूप में पालन करना चाहिए। अपवाद हैं, उदाहरण के लिए the use of <> vs. "" in #include statements, लेकिन इन अपवादों को आवश्यकता से आना चाहिए।
लोगों को यह सुनाने का सबसे आम कारण है कि स्टाइल दिशानिर्देश आवश्यक क्यों हैं, एक सामान्य शैली में लिखे गए कोड को अलग-अलग शैलियों में लिखे गए कोड को बनाए रखना आसान है। मैं असहमत हूं। एक पेशेवर प्रोग्रामर फंस जा करने के लिए जब वे यह देखने नहीं जा रहा है:
for(int n = 0; n < 42; ++42) {
// blah
}
... जब वे इस को देखने के लिए उपयोग किया जाता है:
for(int n = 0; n < 42; ++42)
{
// blah
}
इसके अलावा, मैं ने पाया है कि यह वास्तव में आसान है कुछ मामलों में कोड बनाए रखें यदि आप प्रोग्रामर की पहचान कर सकते हैं जिन्होंने अपनी शैली को पहचानकर मूल कोड लिखा था। उनसे पूछें कि उन्होंने एक दिन के बेहतर हिस्से को खर्च करने के बजाय 10 मिनट में इस तरह के घुलनशील तरीके से जीजीएम को क्यों लागू किया, ताकि तकनीकी कारणों का पता चल सके कि उन्होंने कुछ अप्रत्याशित क्यों किया। सच है, प्रोग्रामर को अपने तर्क की व्याख्या करने के लिए कोड पर टिप्पणी करनी चाहिए थी, लेकिन असली दुनिया प्रोग्रामर अक्सर नहीं करते थे।
अंत में, यदि यह जो लेता है 10 मिनट & backspacing उसके घुंघराले ब्रेसिज़ चलती ताकि विधेयक 3 कम सेकंड खर्च कर सकते हैं कोड को देखते हुए, यह वास्तव में किसी भी समय बिल कुछ करना बनाने के लिए बचाने के लिए किया था कि उसे करने के लिए प्राकृतिक आता है ?
स्रोत
2008-10-08 21:55:45
आपका उत्तर बिल्कुल मेरे अनुभवों को बताता है। टीमों को अपने मानकों को परिभाषित करना चाहिए, जिसका लाभ यह है कि टीम के हर सदस्य ने उनमें एक कहा है (जिसे हम "खरीद-इन" कहते हैं)। हमारी टीम के नेता ने शायद ही कभी शैली पर "तानाशाही" निर्णय लिया, जब तक सर्वसम्मति तक नहीं पहुंचे, तब तक हमेशा चर्चा की जाती थी। –
मैं असहमत हूं। लोगों के बाद, एक सॉफ्टवेयर कंपनी का सबसे मूल्यवान संसाधन कोड है। टीमों के बीच मानकों की आवश्यकता होती है, अन्यथा प्रत्येक टीम एक द्वीप के अधिक से अधिक हो जाती है। और क्या होता है जब कोई टीम सदस्य किसी अन्य टीम में जाता है? ओह, नए "मानक" –
मुझे व्यक्तिगत अनुभव के माध्यम से मिला है और विभिन्न टीमों के साथ काम करना है जो प्रचार करने की सबसे आसान शैली है जो सबसे कमजोर है। यही है, विदेशी स्वरूपण, नामकरण योजनाओं आदि के साथ प्यार गिरने से बचें - पूरे केआईएसएस दर्शन। हम में से उन लोगों के लिए जिन्हें लेखकों की एक बड़ी विविधता से कोड के साथ काम करना पड़ा है, हम कई अलग-अलग शैलियों में उपयोग करते हैं ... वास्तव में उन विदेशी लोगों को छोड़कर जो सभी प्रकार के नए सम्मेलनों और स्वरूपण शैलियों को पेश करते हैं। इसे थोड़ा नीचे दबाएं और हम सभी के लिए एक ही पृष्ठ पर होना बहुत आसान होगा। – stinky472