सबसे खराब कोडिंग मानक जिसका आपको कभी पालन करना पड़ा है? [बन्द है]

Question

क्या आपने कभी मानकों को कोड करने के लिए काम किया है:

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

यदि हां, तो आपका सबसे कम पसंदीदा नियम क्या है और क्यों?

---

कुछ उदाहरण यहाँ

Comments

मैंने इसी तरह से एसओ पर एक समान प्रश्न (लेकिन बिल्कुल वैसा ही नहीं) पूछा है: stackoverflow.com/questions/218123/…

— ब्रायन आर। बॉडी

@ ब्रायन, धन्यवाद, मैंने आपका प्रश्न देखा था लेकिन इसके बारे में भूल गया।

— फाइनेंशियल

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

— इंटर्नसेन

Answer 1

यह कुछ पंखों को रगड़ सकता है, लेकिन मानक जो प्रत्येक विधि के शीर्ष पर टेम्प्लेट किए गए ब्लॉक टिप्पणियों को अनिवार्य करते हैं, हमेशा मेरे लिए बकवास को बग देते हैं।

1) वे हमेशा से पुराने हैं क्योंकि वे उस कोड से बहुत दूर हैं जो चीजों को अपडेट करते समय ध्यान देने के लिए वास्तविक काम करता है। खराब टिप्पणियां, किसी भी टिप्पणी से बदतर हैं।

2) वे अक्सर केवल उन सूचनाओं को दोहराते हैं जो पहले से ही स्रोत नियंत्रण उपकरण में निहित हैं, बस कम सटीक। उदाहरण के लिए: अंतिम संशोधन द्वारा, संशोधन तिथि / कारणों की सूची।

Comments

मुझे पता है (कम से कम अब, पहले स्कूल में जो अजीब लग रहा था) कि पूरी तरह से टिप्पणी करना एक बुरा व्यवहार है

— Shady M. Najib

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

— गज

असहमत! हम बेकार अयस्क reduntand जानकारी नहीं जोड़ते हैं, लेकिन फ़ंक्शन क्या (.h फ़ाइल में) करता है और यह कितना उपयोगी है, इसका एक वास्तविक पाठ्य विवरण है! बेशक हम इसे कोड के साथ सिंक में बनाए रखने के लिए प्रतिबद्ध हैं।

— जादूगर

@ शदी एम नजीब हमेशा बुरा या बुरा जब अनियंत्रित / बिना जाने के लिए अनुमति दी? आम तौर पर, अच्छा कोड टिप्पणी के लिए आवश्यकता से बचने के लिए अपने उद्देश्य को स्पष्ट कर देगा - लेकिन यह हमेशा ऐसा नहीं होता है और मुझे लगता है कि इन परिदृश्यों में टिप्पणी करना महत्वपूर्ण है। मैं XMLDoc टिप्पणियों को शामिल करने के एक बुरे कारण के बारे में नहीं सोच सकता।

— नाथन टेलर

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

— 16

Answer 2

एक बार प्रोफेसर थे जिन्होंने मांग की थी कि हमारे पास कोड की प्रत्येक पंक्ति के लिए कम से कम एक टिप्पणी हो।

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

यह बहुत हास्यास्पद था।

Comments

क्या यह सिर्फ इतना नहीं है कि प्रोफेसर को पता है कि आप जानते हैं कि वास्तव में क्या चल रहा है?

— जॉन मैकइंटायर

मुझे लगता है कि यह स्पष्ट है कि क्या चल रहा है, और यह शिक्षा नहीं है।

— राय में दान रे

आपके पास ऊपर दिया गया उदाहरण स्पष्ट है, लेकिन क्या होगा यदि कोई छात्र किसी अन्य ऐप या किसी पुस्तक से किसी फ़ंक्शन को कॉपी करता है या कभी भी, और वास्तव में इसे नहीं समझता है? प्रोफेसर को कैसे पता चलेगा? यह मूर्खतापूर्ण नियम किसी भी ग्रे क्षेत्र (जो अपने बचाव में, संभवतः पहले दुर्व्यवहार किया गया है) की अनुमति नहीं देता है। यही मैं इसकी व्याख्या करता हूं। ... आप बुरा मानें अगर मैंने इसे गैर-शैक्षणिक माहौल में देखा तो यह मुझे थोड़ा डरा सकता है। ;-)

— जॉन मैकइंटायर

हाँ, सिवाय आप हमेशा ऐसी टिप्पणियाँ लिख सकते हैं जो सिर्फ कोड दोहराएं और कोई समझ न दिखाएं। क्या वह आपको अंत में ब्रेस से पहले "// एंडिंग ब्रेस" बनाता है?

— वैकल्पिक

क्या होगा यदि आपने गलती से अपने कोड में एक उपयोगी टिप्पणी प्राप्त की है? क्या आपको // commentइससे पहले लाइन पर लगाने की आवश्यकता है?

— विन्यासकर्ता

Answer 3

हमारी कंपनी (C #) कोडिंग मानक को #REGIONs के व्यापक उपयोग के लिए कहा जाता है (जो नहीं जानते हैं, यह स्रोत कोड के ब्लॉक को चिह्नित करता है जो विज़ुअल स्टूडियो में एक ही लाइन से टकरा जाएगा)। परिणामस्वरूप, आपने हमेशा खोला कि एक अच्छी तरह से संरचित वर्ग प्रतीत होता है, केवल #REGION निर्माण के गहरे घोंसले के नीचे कूड़े के ढेर और ढेर खोजने के लिए। आपके पास एकल लाइनों के आसपास के क्षेत्र भी होंगे, उदाहरण के लिए, लकड़हारे की एक एकल घोषणा को खोजने के लिए एक लॉग क्षेत्र को फोल्ड आउट करना। बेशक, कुछ क्षेत्र बनाने के बाद बहुत सारे तरीके जोड़े गए, उन्हें "गलत" क्षेत्र के दायरे में भी रखा गया। डर। डर।

क्षेत्र दृश्य स्टूडियो में जोड़े गए सबसे खराब विशेषताओं में से एक हैं ; यह वास्तविक OO संरचना के बजाय सतह की संरचना को प्रोत्साहित करता है।

आजकल, मैं #REGIONs को दृष्टि से मारता हूं।

Comments

मैंने इसे एक दर्जन बार वोट देने की कोशिश की ...

— TGnat

अगर आपको लगता है कि आपको #REGION की आवश्यकता है, तो मुझे लगता है कि आपको रिफ्लेक्टर की आवश्यकता है।

— जे बज़ुज़ी

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

— इवान प्लाइस

हमारे पास एक साधारण कोडिंग मानक है: कभी भी घोंसला क्षेत्र नहीं । बस उन्हें समूह से संबंधित तरीकों (आरंभीकरण, क्रमांकन, गुण, आदि) के लिए उपयोग करें

— जेसन विलियम्स

#Regions का एकमात्र अच्छा उद्देश्य कोड को छिपाना है जिसे संपादित करने की आवश्यकता नहीं है । यह कोड, या एक मुश्किल-से-सही एल्गोरिथ्म के साथ कोड उत्पन्न किया जा सकता है, जिसे आप लोग स्पर्श नहीं करेंगे, या शायद बदसूरत-डिबगिंग-कोड ब्लॉक। लेकिन ऐसा कोड नहीं, जिस पर लोग काम कर रहे हों। # भाग की दुकान में फंसे लोगों के लिए, मेरे पास एक मैक्रो है जो परिभाषाओं के साथ टकराता है लेकिन क्षेत्रों का विस्तार करता है। यहां देखें: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…

— Kyralessa

Answer 4

एक काम में हमें डेटाबेस में हंगेरियन नोटेशन के कुछ अजीब रूप का उपयोग करने के लिए मजबूर किया गया था ।

मुझे विवरण याद नहीं है, लेकिन स्मृति से, प्रत्येक क्षेत्र का नाम शामिल करना था:

• कोई स्वर नहीं
• सभी बड़े अक्षर
• तालिका का संदर्भ
• एक डेटा प्रकार संकेतक
• एक डेटा लंबाई
• एक अशक्त सूचक

उदाहरण के लिए, किसी व्यक्ति का पहला नाम रखने वाले कॉलम को कहा जा सकता है: PRSNFRSTNMVC30X(व्यक्ति तालिका, पहला नाम कॉलम, वर्चर 30 अक्षर, नॉट नंबर्स)

Comments

क्षमा करें, लेकिन क्या होता है जब आप डेटाबेस को रिफलेक्टर करते हैं या जब आप यह निर्णय लेते हैं कि VARCHAR की लंबाई अलग होनी चाहिए। अचानक, आपको अपने सभी कोड के माध्यम से जाना और बदलना होगा ... हे भगवान। जो भयावह लग रहा है।

— टॉम मॉरिस

स्वर नहीं ?? तुम मजाक कर रहे हो ना?

— डैनियल कैसिडी

क्या इस मानक को लागू करने वाले लोगों के माथे पर लकीरें होती हैं और वे अक्सर सम्मान और लड़ाई पर चर्चा करते हैं?

— रियान रॉबर्ट्स

हाहा, अच्छी तरह से वे डीबीए थे, इसलिए ...;)

— दामोविसा

आपको एक url शॉर्टनर के माध्यम से अपने कॉलम के नाम भेजने चाहिए। PersonFirstNameVarchar30NotNull = bit.ly/cULlQc

— बिली कोवर

Answer 5

जोर देकर कहते हैं कि ब्रेस समाप्त होने के लिए सभी ब्रेसिज़ का अनुसरण किया जाना चाहिए:

उदाहरण के लिए:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

Comments

अधिक अनुकूलनीय: यदि आपको यह कहने के लिए एक टिप्पणी की आवश्यकता है कि ब्लॉक की शुरुआत क्या थी, तो ब्लॉक बहुत लंबा है, या इसकी सामग्री बहुत जटिल है => रिफ्लेक्टर।

— रिचर्ड

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

— २०:०२ पर जे बाज़ूजी

यह एक शक्तिशाली आईडीई के साथ एक दुनिया के लिए एक महान विचार था।

— एडेप्टर

@ किसी भी सभ्य IDE में आप एक ब्रेस को हाइलाइट कर सकते हैं और यह अन्य संबंधित ब्रेस को हाइलाइट करेगा। मैं व्यक्तिगत रूप से घृणा करता हूं जब लोग ऐसा करते हैं।

— इवान प्लाइस

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

— जस्टर्नबर्ग

Answer 6

#define AND  &&
#define OR   ||
#define EQ   ==

'निफ ने कहा।

Comments

क्या #include <iso646.h> ज्यादा बेहतर विकल्प नहीं होगा?

— आंद्रेजाको

@AndrejaKo: यह पूर्ववर्ती <iso646.h> है; यह फोरट्रान की तरह सी दिखने का प्रयास था।

— नियाल सी।

क्या यह वास्तव में एक कोडिंग मानक था? यानी सीधे ऑपरेटरों को लिखने के खिलाफ एक कंपनी की नीति थी?

— फिन

क्या यह #define BEGIN {और भी था #DEFINE END }?

— JBRWilkinson

यह मुझे एक डेली डब्ल्यूटीएफ लेख की याद दिलाता है, जिसमें मैंने देखा कि कुछ सी ++ प्रोग्रामर में एक टन डिफाइन होता है ताकि यह विज़ुअल बेसिक (या शायद सिर्फ बेसिक, कुछ बोली) की तरह दिख सके। #define void Sub, #define} अंत, जैसी बातें।

— वेन मोलिना

Answer 7

• स्थानीय चर नाम बिना किसी अंडरस्कोर के सभी निचले होते हैं

रियल उदाहरण: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

न्यूयॉर्क टाइम्स का वजन :

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

Comments

+1। मामूली झुंझलाहट बढ़ जाती है। इसके अलावा, उनके खिलाफ बहस करना कठिन है क्योंकि कोडिंग मानकों के संपादक या पीएम कह सकते हैं "यह कोई बहुत बड़ा बोझ नहीं है इसलिए यह इसे बदलने के लायक नहीं है।"

— फाइनेंशियल

ठीक ठीक। (हालांकि इस मामले में, umpteen varablenameslike thiscanreally adduptoquitea greatburden पढ़ना।)

— जॉन सिराकुसा

नाम का आविष्कार करने के बजाय दो तरीकों से खुद को मनोरंजन करें। पेजशिट्स, पेनिसअप, आदि

— जे बाज़ुज़ी

@ जय * सेक्सचेंज

— विन्यासकर्ता

@configurator: जब विज़ुअल स्टूडियो डीबगर टीम एक सुविधा पर काम कर रही थी, ताकि आप घड़ी की खिड़की में वर्तमान में उड़ान के अपवाद को देख सकें, तो वे "$ ex" नामक एक छद्म चर जोड़ने जा रहे थे। हमने लंबे समय तक नोटिस नहीं किया। फिर हमने "$ अपवाद" का नाम बदल दिया, लेकिन मैंने अभी भी इसे 's' होने के रूप में पढ़ा।

— Jay Bazuzi

Answer 8

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

हमें मर्ज सॉफ़्टवेयर का उपयोग करने से भी मना किया गया था; प्रत्येक फ़ाइल को एक समय में केवल एक प्रोग्रामर द्वारा संशोधित किया जा सकता है। संशोधन नियंत्रण सॉफ्टवेयर निश्चित रूप से विज्ञान कथा थी।

मेरे जीवन का सबसे ख़ुशी का दिन था जब उसे निकाल दिया गया था (विचार करें कि इटली में किसी को गोली मारना बहुत मुश्किल है)।

Comments

उन्होंने

— नंद

उसने कभी बहुत सारे दूसरे शब्द भी नहीं सुने ...

— जादूगर heard

वैसे आपको औपचारिक परीक्षण की आवश्यकता नहीं थी क्योंकि आपने कभी तरीके नहीं बदले ...

— विन्यासकर्ता

Answer 9

डेटाबेस के साथ सभी इंटरैक्शन को संग्रहीत प्रक्रियाओं के माध्यम से किया जाना है । यह समझ में आ सकता है अगर हम 1997 में रह रहे हैं और 2010 में नहीं।

मुझे बस एहसास हुआ कि यह वास्तव में मूल प्रश्न के सभी मानदंडों को शामिल करता है:

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

Comments

मुझे अपने कार्यस्थल में इस शिविर में कुछ लोग मिले हैं। यह मजेदार है जब वे प्रदर्शन कार्ड खेलने की कोशिश करते हैं और प्रदर्शित करते हैं कि उनका ज्ञान कितना पुराना है

— डॉक्टर जोन्स

रुको .. सभी गंभीरता से, मैंने सोचा कि एसपी के बेहतर, प्रदर्शन के लिहाज से, सीधे एसक्यूएल कॉल से बेहतर है, कहते हैं, सी #?

— Sk93

लगता है जैसे आप जानते हैं कि वे क्यों शामिल थे। : पी

— मेसन व्हीलर

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

— जे क्यू कतार

मैंने सुना है प्यारा तर्क "हम एक OR / M का उपयोग नहीं कर सकते क्योंकि सभी इंटरैक्शन SPs का उपयोग करना चाहिए"। मानव-शक्ति का ऐसा अपव्यय।

— विन्यासकर्ता

Answer 10

एसटीएल या अन्य मानक C ++ पुस्तकालयों का उपयोग करने की अनुमति नहीं दी जा रही है क्योंकि CTO का मानना ​​है कि 'हम' इसे बेहतर और तेज़ कर सकते हैं। यहां तक ​​कि बुनियादी निर्माण जैसे सूचियां और स्ट्रिंग वर्ग।

Comments

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

— मैट ओलेनिक

@ मैट: इसे जोड़ने के लिए, ईए शिकायत मेमोरी उपयोग और आरंभीकरण पर केंद्रित थी। उनके स्वयं के कार्यान्वयन ने कम मेमोरी का उपभोग किया, इसे जल्द ही जारी किया, और शुरुआती वस्तुओं को टाल दिया, जिन्हें बाद में आरंभीकृत किया जाएगा।

— Matthieu एम।

मैं उसे खुद इसे कोड करने के लिए कहूंगा।

— दक्षिणावर्त

Answer 11

हंगेरियन अंकन

MSDN पर " चार्ल्स सिमोनी के हंगेरियन अंकन पहचानकर्ता नामकरण सम्मेलन के अन्वेषण " से निकाला गया नमूना ।

1 # ईमानदारी "sy.h"
2 बाहरी int * rgwDic;
3 बाहरी int bsyMac;
4 संरचना SY * PsySz (char sz [])
6 {
7 चर * पच;
8 int cch;
9 संरचना SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 अहस्ताक्षरित wHash = 0;
13 pch = sz;
14 जबकि (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 के लिए (? * Pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 चार * szSy;
21 szSy = (psy = (स्ट्रक्चर SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 जबकि (* pch == * szSy ++)
24 {
25 यदि (* pch ++ == 0)
26 वापसी (psy);
27}
28}
29 cwSz = 0;
30 अगर (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 शून्य ((int *) psy, cwSY);
34 ब्लटबाइट (sz, psy-> sz, cch + 1);
35 वापसी (psy);
36}

Comments

ओउ ओउ ओउ ओउ ओउ ओउ!

— डॉक्टर जोन्स

इस नमूने के साथ सबसे बड़ी समस्या व्यर्थ चर नाम है। हंगरी उपसर्गों को दूर करें और उनमें से कुछ 1 या यहां तक ​​कि 0 वर्ण लंबे हैं।

— 18

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

— जेसन विलियम्स

ओह कृपया। मैं कभी नहीं किया है कभी एक सदस्य के साथ एक स्थानीय उलझन में है, और मैं सदस्यों / स्थानीय लोगों / क्षेत्रों के लिए है कि मूर्ख हंगेरी का उपयोग नहीं करते / जो कुछ भी। मुझे लगता है कि वे विभिन्न प्रकार के तारों के बीच अंतर करने के लिए उपयोगी हो सकते हैं, जैसे 'सुरक्षित' और 'असुरक्षित', जैसे गलत कोड बनाने

— विन्यासकर्ता

@configurator: जोएल का उदाहरण भयावह है, वह विभिन्न प्रकार के होने से बेहतर होगा, फिर कंपाइलर उपयोग को लागू करेगा।

— मैथ्यू एम।

Answer 12

मैंने एक बार एक परियोजना पर काम किया था जिसमें परियोजना का नेतृत्व अनिवार्य था कि हर चर - हर चर - "v" के साथ उपसर्ग हो। तो, vCount, vFirstName, vIsWarvant, आदि।

क्यों? "क्योंकि हम VBScript में काम कर रहे हैं और सब कुछ वैसे भी एक वेरिएंट है"।

WTF।

Comments

मैंने एक बार एक ऐसी भाषा में काम किया है जिसमें हर चर की आवश्यकता होती है - हर चर - "$" के साथ उपसर्ग किया जाना चाहिए।

— दोपहर

@ क्या: और आपको पता चला कि यह आश्चर्यजनक था, क्या आप नहीं थे?

— जोश के

मैंने एक बार ऐसी भाषा में काम किया, जहां मेरे सभी चर '$' या '%' या '@' जैसे विराम चिह्न के साथ शुरू हुए। मैं अब भी करता हूं, अभी और फिर।

— डेविड थॉर्नले

यह केवल वास्तव में एक समस्या बन जाती है जब आपके fकार्यों को पहले कार्य करने की आवश्यकता होती है , तो आपका कोड सही मायने में है fUcked (vUp)।

— जो डी

पर्ल के विभिन्न संस्करणों की तरह लगता है ...

Answer 13

लगभग यह भूल गया:

एक प्रबंधक का उद्धरण:

अपने स्वयं के कोड में पाए जाने वाले मुद्दों के किसी भी कीड़े को ठीक या दस्तावेज़ न करें। ग्राहक हमें अगले कुछ वर्षों में उन्हें पहचानने और उन्हें ठीक करने के लिए भुगतान करेगा।

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

Comments

यह एक भयानक नीति है। मुझे आशा है कि यह प्रबंधक डिब्बाबंद था।

— बर्नार्ड

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

— जिम रश

Answer 14

सभी गैर-निजी तरीकों, स्थिरांक, एनम और गुणों पर लागू XML टिप्पणियाँ।

इसने कुछ बहुत क्लॉट किए गए कोड का नेतृत्व किया, खासकर जब से अंतिम परिणाम लोगों को या तो सब कुछ के लिए एक खाली टिप्पणी स्टब बनाने के लिए ///Doc को स्थापित करने या इसे स्वतः उत्पन्न टिप्पणियों को जोड़ने के लिए /// मार रहा था:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

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

Comments

' Validations the handler' - उह-ओह

— एरिक

+1 ऊग मैं इससे नफरत करता हूं। मुझे लगता है कि यदि आपका सॉफ़्टवेयर टिप्पणियों का उपयोग करने के लिए है, तो आपको उनकी आवश्यकता नहीं है।

— ब्लोवो सेप

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

— फाइनव सिप 9'10

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

— एडम लेअर

अविवादन का क्लासिक मामला। टिप्पणियां जो स्पष्ट रूप से स्पष्ट के अलावा कुछ भी नहीं बताती हैं उन्हें दृष्टि पर मार दिया जाना चाहिए।

— कुम्भाय

Answer 15

वास्तव में एक कोडिंग मानक नहीं है, लेकिन हमारे पास 'changelog.txt' नामक स्रोत नियंत्रण में एक फ़ाइल थी

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

जब नया सीटीओ शुरू हुआ और किसी ने उसे यह बताया, तो उसने तुरंत एक कार्यकारी निर्णय लिया और कहा, "हम अब ऐसा नहीं करने जा रहे हैं" और फ़ाइल को हटा दिया। ऐसा सालों से चल रहा था।

Comments

और किसी को पता नहीं था svn log?

— हतबा

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

— जिम ए

Answer 16

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

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

Comments

मैं हाल ही में बाहर कोड टिप्पणी की एक बहुत हटा रहा हूँ।

— कोडरडैनी

मैं आमतौर पर टिप्पणी किए गए कोड को हटा देता हूं जब तक कि यह एक अच्छी व्याख्या के साथ न हो कि यह टिप्पणी क्यों की गई है और इसे क्यों रखा जाना चाहिए।

— जेरेमी वाइबे

मैं पूरी तरह सहमत हूँ। जब तक आप इसके साथ काम करते हैं, तब तक कोड टिप्पणी करना ठीक है, लेकिन रिलीज संस्करण / मुख्य शाखा में जाने वाली हर चीज टिप्पणी कोड से रहित होनी चाहिए। किसी ने मुझे बताया कि वे "यह जानना पसंद करते हैं कि यह अलग तरीके से कैसे किया जा सकता है"। मैं इसे वर्णित कारणों के लिए परेशान कर रहा हूं: क्या यह अप्रचलित है, इसे हल करने के लिए एक और तरीका है? डब्ल्यूटीएफ

— ऐनी शूसेलर

VS2013 "पीक्स" के साथ यह सब खिड़की से बाहर है। लेकिन हम एक टिप्पणी डालते हैं जो कहती है कि "बदले हुए समीकरण - शुरुआती" या कुछ और, इसलिए किसी को यह सोचकर कि पुराने कोड को TFS / VCS में देखना होगा अगर उन्हें ज़रूरत थी। तो यह 10 टिप्पणी की गई लाइनों के बजाय एक पंक्ति है। लेकिन VS2013 कमाल का है, यह आपके लिए वहीं TFS इतिहास दिखाता है।

— सुमेरे

Answer 17

सबसे खराब कोडिंग मानक जो मैंने कभी भी भाग लिया है, वह कोड आधार है जिसमें कोई भी नहीं था। मैं कोडिंग मानक का पालन करना चाहूंगा, मैं कोड बेस में काम की तुलना में पूरी तरह असहमत हूं जहां कोई भी नहीं है। यह यह बनाता है कि कोड आधार के नए भागों को सीखना बहुत कठिन है।

Answer 18

संस्करण नियंत्रण के लिए मजबूर इनलाइन टिप्पणियाँ मैं नजरअंदाज कर दिया सबसे बेकार कोडिंग मानक के बारे में था।

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

ओरेकल डीबीए जिसमें व्हाट्सएप के सही उपयोग पर जोर दिया गया था, जबकि 200 से अधिक क्षेत्रों और 40 ट्रिगर्स वाले एक डेटाबेस को 'बनाए रखना' करीब आता था।

Comments

यह बहुत जघन्य है

— इवान प्लाइस

Mmm। डिम सम ...

— विन्यासकर्ता

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

— स्कॉट व्हिटलॉक

हमारे वरिष्ठ देव अभी भी हमें ऐसा करने के लिए मजबूर करने की कोशिश करते हैं। जब भी मुझे लगता है कि मैं इसके साथ (और कभी-कभी जब मुझे पता है कि मैं नहीं कर सकता) दूर हो जाता है तो मैं इस नीति को अनदेखा करता हूं।

— जोशुआ स्मिथ

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

— वेन मोलिना

Answer 19

मैंने C ++ फर्स्ट टाइमर की अगुवाई वाली एक परियोजना पर कोड समीक्षा की, जिसने तय किया कि सभी वर्ग सदस्य कार्यों को कक्षा और दृश्यता के साथ उपसर्ग किया जाना चाहिए:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Comments

क्या आपने उनसे पूछा क्यों ? मैं सिर्फ उनकी प्रेरणा जानना पसंद

— करूंगा

वाह, वह आदमी भी कक्षाओं का उपयोग क्यों कर रहा है ?

— मतीन उलहाक

Answer 20

चार स्थानों द्वारा सभी कोड को इंडेंट करना आवश्यक है;)

Comments

यह कैसा बुरा था?

— २०:०२ पर जे बाज़ूजी

क्योंकि तब हर लाइन में शुरुआत में 4 अनावश्यक स्थान होते हैं?

— दोपहर 10:09

ओह, अब मुझे समझ में आ गया।

— वैकल्पिक

हाँ, StackOverflow वास्तव में खराब कोडिंग मानक है। :-)

— पी शेव्ड

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

— तून Krijthe

Answer 21

मेरे पास एक साल पहले नौकरी थी जहां हमारे सभी कोड को छोड़ दिया जाना था - कोई इंडेंटिंग नहीं। उस नीति के साथ आने वाले व्यक्ति को कोड की लंबी पंक्तियों को देखने, उसकी आंखों के साथ पिंग-पोंग खेलने के बराबर होने पर क्षैतिज रूप से आगे और पीछे स्क्रॉल करने के लिए नापसंद किया गया था।

Comments

यह एक भयानक, भयानक कोडिंग मानक का पालन करना है। और इसके लिए एक बेवकूफ कारण भी!

— गैबलिन

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

— हतबा

Answer 22

यह अधिक उदाहरण है कि कैसे कोडिंग मानकों का नहीं होना चोट पहुंचा सकता है।

एक बड़े बैंक में काम करने वाले एक ठेकेदार ने जोर देकर कहा कि मानकों का पालन करना सबसे अच्छा था। आवेदन dBase / Clipper में लिखा गया था, जिसके लिए वह एकमात्र डेवलपर था और निश्चित रूप से वह मानक के साथ आया था।

• सब कुछ ऊपरी मामले में है। मेरा मतलब है कि उसने जो भी टिप्पणी की है, वह सब कुछ है।
• कोई इंडेंटेशन नहीं।
• चर नामकरण APRGNAME की तर्ज पर कुछ था। वेरिएबल का एक = स्कोप, उदाहरण के लिए P, पब्लिक के लिए, PRG = सोर्स फाइल के पहले तीन कैरेक्टर जिन्होंने वैरिएबल बनाया, बाकी 6 कैरेक्टर्स में NAME = वैरिएबल नेम जिसे dBase / Clipper ने अनुमति दी।
• स्रोत कोड की पहली 4 और अंतिम 4 लाइनें 80 * लंबी थीं। क्यों? इसलिए वह डॉट मैट्रिक्स प्रिंटर को एक फाइल की प्रिंटिंग शुरू करने और खत्म करने के लिए सुन सकता था। मेमोरी पूरे कार्यक्रम को मेनफ्रेम साप्ताहिक, 20,000 पृष्ठों के माध्यम से मुद्रित किया गया था।
• मुझे यकीन है कि कई और भी थे जो मैंने अपने मस्तिष्क से डंप करने में कामयाब रहे हैं।

मैं उस चरण में एक बहुत ही नया स्वयं-सिखाया प्रोग्रामर था, लेकिन पागल वैज्ञानिक को सुनने और परियोजना को संभालने से पहले नरक से बाहर निकलने के लिए पर्याप्त नहीं जानता था।

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

Comments

कृपया पुराने डायनासोर का मजाक न उड़ाएं। उन्होंने हमें संभव बनाया।

— पी शेव्ड 11'10

नौकरी की सुरक्षा जैसा लगता है।

— एमआईए

एक ऑडियो मार्कर होने से आपको पता चलता है कि जब प्रत्येक फ़ाइल मुद्रण कर रही है तो सरल है। मैं \07अब प्रत्येक फ़ाइल के प्रारंभ में जोड़ने जा रहा हूँ ।

— विन्यासकर्ता

इस तरह की नामकरण योजना (ऊपरी मामला नहीं) का उपयोग करना कुछ मायने रखता है क्योंकि dBase के परिवर्तनशील "स्कूपिंग" नियम गैर-विद्यमान थे। सब कुछ प्रभावी रूप से वैश्विक था। एक iसरणी को एक प्रक्रिया में अनुक्रमित करने के लिए iएक कॉलिंग प्रक्रिया में एक के साथ हस्तक्षेप कर सकता है । आपको इस "शैडोइंग" को रोकने PRIVATE ALL LIKE m*और उपयोग करने की आवश्यकता हैPRIVATE i

— गेरी

Answer 23

मेरे अतीत से एक और विस्फोट।

कंपनी के मालिक का उद्धरण:

व्याख्यात्मक भाषाओं का उपयोग करते हुए कोई कोड नहीं लिखा जाएगा क्योंकि मैं जावा में लिखे गए उस {एक्सप्लेटिव} प्रोजेक्ट पर 25 मिलियन हार गया हूं।

जावा परियोजना एक स्टॉक ट्रेडिंग सिस्टम था जिसे कुछ दर्जन शेयरों को संभालने के लिए डिज़ाइन किया गया था, जिसका उपयोग अब हजारों को संसाधित करने के लिए किया जा रहा है। डिज़ाइन दोषों या खराब हार्डवेयर को संबोधित करने के बजाय, पूरी कंपनी को सभी गैर C / C ++ अनुप्रयोगों को C / C ++ में परिवर्तित करने के लिए मजबूर किया गया था, और सभी नए विकास C / C ++ में होने थे। व्याख्यात्मक भाषाओं का मतलब कुछ भी नहीं संकलित है, और मालिक केवल असेंबलर, सी और सी ++ को संकलित मानते हैं।

एक 800 व्यक्ति कंपनी के लिए, जिसमें अधिकांश कोड जावा और पर्ल में थे, इसका मतलब था कि पूरी कंपनी ने अगले कुछ वर्षों में अपना अधिकांश समय C / C ++ में पूरी तरह से ठीक कोड लिखकर खर्च किया।

काफी मजेदार है, इस उपद्रव से कुछ बीस साल पहले, मैं एक अन्य कंपनी में था, जिसमें टेक लीड ने फैसला किया था कि हमारे सॉर्टिंग लॉजिक (यह एक बबल सॉर्ट था) को त्वरित सॉर्ट द्वारा प्रतिस्थापित किए जाने के बजाय कोडांतरक में पुन: व्यवस्थित करने की आवश्यकता थी क्योंकि - एल्गोरिदम प्रदर्शन में सुधार नहीं। प्रदर्शन में सुधार करने का एकमात्र तरीका कोडांतरक में समान तर्क को फिर से लिखना था।

दोनों ही मामलों में, हुकुमों के कम होने के तुरंत बाद मैंने छोड़ दिया।

Comments

क्या आज भी कंपनी चल रही है?

— फाइननव

जावा से जो long मूव ’किया गया है, वह दूसरा गया है। वे टीआरएस -80 से एक पीसी तक कदम से कभी नहीं बच पाए।

— डेविड बी

Answer 24

बहुत सारे प्रोग्रामर (लेकिन पर्याप्त नहीं) की तरह, मुझे कोड सजावट से नफरत है। यह मुझे तब प्रभावित करता है जब मुझे चर नाम ($) उपसर्ग का उपयोग चर नामों के लिए करना पड़ता है, या निजी चर के लिए अंडरस्कोर, यहां तक ​​कि बिना गेटर्स / सेटर के भी। यदि आपको इसे समझने के लिए आपको कोड को सजाने की ज़रूरत है, तो आपको नरक से बाहर निकलने की आवश्यकता है!

Comments

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

— 7wp

मुझे नहीं लगता है कि अपने पसंदीदा स्वामित्व आईडीई में एक साथ अपने चर को समूहीकृत करना आपके सभी कोड को ख़राब करने का एक अच्छा कारण है।

— आदम हर्ट

यदि यह आपका कोड है, तो यह आपके IDE में प्रयोग करने योग्य है, पूरी तरह से उचित है। इसके अलावा, अंडरस्कोर को रोकना कई भाषाओं में आम है, इसलिए जब भी लोग इसे देखते हैं, वे जानते हैं कि इसका क्या मतलब है।

— rjmunro

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

— वैकल्पिक

उच्छ्वास ... उन लोगों में से एक "आईडीई के पूसी लोगों के लिए हैं"।

— नाखून

Answer 25

मैं थोड़ी देर के लिए एक वेब प्रणाली के साथ काम कर रहा हूं, जहां पारित किए गए सभी मापदंडों को पी 1, पी 2, पी 3 आदि नाम दिए जाने थे, नर्क में कोई मौका नहीं है यह जानने के लिए कि वे व्यापक प्रलेखन के बिना क्या करते हैं।

इसके अलावा - हालांकि सख्ती से एक कोडिंग मानक नहीं है - एक ही प्रणाली में, हर एक फ़ाइल का नाम xyz0001.ext, xyz0002.ext, xyz0003.ext, आदि होना था - जहां xyz अपने आप में एप्लिकेशन के लिए कोड था।

Answer 26

यह एक लंबा समय पहले था - 1976 सटीक होना। मेरे बॉस ने कभी भी एग्ज़र दीजकस्ट्रा के बारे में नहीं सुना था या सीएसीएम का एक मुद्दा नहीं पढ़ा था, लेकिन उन्होंने कहीं से एक अफवाह सुनी थी कि "गोटो खराब है", इसलिए हमें अपने कॉबोल कार्यक्रमों में गोटो का उपयोग करने की अनुमति नहीं थी। इससे पहले कि COBOL "एंड इफ़" को जोड़े, इससे पहले उस समय तीन क्लासिक कंट्रोल स्ट्रक्चर्स का केवल ढाई हिस्सा था (अनुक्रम, अगर / फिर / तो, प्रदर्शन करें (यानी करते समय)। उन्होंने हमारे मूल कार्यक्रमों में, और हमारे असेंबलर भाषा कार्यक्रमों में शाखा निर्देशों के लिए GOTO की अनुमति दी।

क्षमा करें कि यह "आप वहाँ होना था" कहानी का एक प्रकार है। जहां तक ​​मुझे पता है, 1976 से आविष्कार की गई प्रत्येक भाषा में पर्याप्त नियंत्रण संरचनाएं हैं, ताकि आपको कभी भी GOTO का उपयोग करने की आवश्यकता न हो। लेकिन बात यह है कि, बॉस को कभी नहीं पता था कि WHY GOTO को हानिकारक माना जाता था, या कौन सी भाषा शिशु विकार थी और कौन सी घातक बीमारी थी।

Answer 27

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

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

यहां तक ​​कि ReSharper ने आपको बताया कि यह गलत है!

Comments

आपको शून्य के रूप में घोषित फ़ंक्शन से कुछ वापस करने के लिए कड़ी मेहनत करनी होगी।

— मिरकिया चिरिया

@MAttB विचार करें कि अंतिम ( else) शाखा को किन स्थितियों में लिया जाएगा।

— रिचर्ड

और {वापसी स्ट्रिंग। खाली; } निष्पादित करेगा जब ऊपर की 2 पंक्तियों को अब से 5 साल बाद एक रखरखाव डेवलपर द्वारा संपादित किया गया है। हालांकि, लौटने वाली स्ट्रिंग। ईएमपी इस तथ्य को छिपाएगी जिसका उपयोग असंभव स्थिति के लिए किया जाता है । इसके बजाय InvalidOperationException को फेंक देना चाहिए ("यह कोड तीन मूल्य तर्क का समर्थन करने का इरादा नहीं था");

— मैथ्मार्टिन

यह भयावह है। इसमें गलत क्या है return verbose ? someString : someOtherString;?

— कैलम रोजर्स

@callum टर्नेरी संचालक पर प्रतिबंध लगाया जा सकता है :) इससे पहले ...

— hplbsh

Answer 28

मेरी आखिरी नौकरी में, "मानकों" के लिए एक बहुत मजबूत शब्द होगा जो मुझे उस व्यक्ति द्वारा दिया गया था जिसने मुझे काम पर रखा था। ColdFusion और SQL में प्रोग्रामिंग वेबसाइट , मुझे कोडिंग आवश्यकताएं दी गई थीं:

• का उपयोग न करें। मुझे एक बड़ा पेज पसंद है
• अंडरस्कोर (स्तंभकारक, प्रथमनाम, आदि को छोड़कर) चर और स्तंभ नामों में हमेशा अलग-अलग शब्द
• कभी भी संक्षिप्ताक्षर का उपयोग न करें - हमेशा firstname लिखें (वह अक्सर fname और इसके बाद लिखे)
• भ्रामक नामों का उपयोग न करें (जैसे amount_charged और charge_amount, जो अलग-अलग लेकिन संबंधित चीजों को मापा जाता है)
• DIV का उपयोग न करें , और न्यूनतम CSS का उपयोग करें - इसके बजाय नेस्टेड तालिकाओं का उपयोग करें (मुझे कुछ छः परतें गहरी, एक बार मिली)।
• किसी भी प्रश्न को कैश न करें। कभी।
• एक से अधिक पृष्ठ पर एक चर का उपयोग करने के लिए जा रहे हैं? आवेदन की गुंजाइश।
• प्रत्येक पृष्ठ का अपना प्रयास / कैच ब्लॉक है। हमें वैश्विक त्रुटि हैंडलर की आवश्यकता नहीं है / चाहिए।

मैंने उनके निकलते ही उन्हें बदलना शुरू कर दिया।

Comments

"भ्रमित करने वाले नामों का उपयोग न करें" मुझे काफी उचित लगता है ...

— 8128

यह बिल्कुल उचित दिशानिर्देश है। मेरा कहना था कि उसने इसका बिल्कुल भी पालन नहीं किया। मुझे लगता है कि उनके विचार "भ्रमित नहीं" थे और मेरा अलग था।

— बेन डूम

Answer 29

C ++ कोडर के रूप में मेरे जीवन में, वास्तव में दो "नियम" लागू किए गए थे:

1. "हम STL का उपयोग नहीं कर सकते, क्योंकि VC ++ 4.1 इसका समर्थन नहीं करता है (और हम इस समय VC ++ 6.0 पर स्विच नहीं कर सकते हैं)।"
2. " क्विकॉर्ट का उपयोग न करें, क्योंकि यह खराब मामलों में ओ (एन ^ 2) हो सकता है; एक छात्र के रूप में लिखे गए हीप्सर्ट एल्गोरिथ्म I (परियोजना नेता का नाम हटा दिया गया) के इस कार्यान्वयन का उपयोग करें।"

Comments

प्रोजेक्ट लीड के हेस्पोर्ट में क्या गलत था?

— 7wp

वास्तव में अगर कोड ने बाहरी उपयोगकर्ता इनपुट को स्वीकार किया तो क्विकॉर्ट गलत हो सकता है क्योंकि यह O(n^2)डॉस के हमलों (सबसे खराब स्थिति वाले इनपुट को फीड करने) के लिए खुलता है । इसके अलावा स्विच करना क्यों संभव नहीं था - यह स्वयं STL का उपयोग नहीं करने का वैध बहाना था।

— मैकीज पीचोटका

Answer 30

मैं सभी वर्गों और वर्ग के सदस्यों के लिए XML प्रलेखन के लिए मजबूर हूं। निजी सहित। मैं डिफ़ॉल्ट घोस्टॉक टिप्पणियों का उपयोग करने के लिए उत्सुक हूं।

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}

Comments

इसके पहले के उत्तर के समान ही ।

— फाइनेंशियल सेप

हाँ। आप सभी को मैं निजी सदस्यों को भी टिप्पणी करना चाहता हूं। जिससे समझदारी भी कम होती है।

— कार्ल बर्गक्विस्ट

Ghostdoc का उपयोग करने के लिए प्रोत्साहित किया ?! गह

— विन्यासक