कोड को देखते समय कौन सी चीजें तुरंत खतरे की घंटी बजाती हैं? [बन्द है]

Question

मैंने कुछ हफ़्ते पहले एक सॉफ़्टवेयर शिल्प कौशल कार्यक्रम में भाग लिया था और टिप्पणियों में से एक था "मुझे यकीन है कि हम सभी बुरे कोड को पहचानते हैं जब हम इसे देखते हैं" और सभी ने बिना किसी चर्चा के शिष्टता से सिर हिलाया।

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

मैं एक आसान से शुरुआत करूँगा:

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

Comments

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

— टेलोनक्स

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

— क्रिस कुडमोर

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

— टिन मैन

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

— पॉल नाथन

हम्म। printf("%c", 7)आम तौर पर मेरे लिए खतरे की घंटी बजती है। ;)

Answer 1

/* Fuck this error */

आमतौर पर एक बकवास try..catchब्लॉक के अंदर पाया जाता है , यह मेरा ध्यान खींचने के लिए है। बस के बारे में भी /* Not sure what this does, but removing it breaks the build */।

कुछ और बातें:

• कई नेस्टेड जटिल ifबयान
• एक नियमित आधार पर तर्क प्रवाह निर्धारित करने के लिए उपयोग किए जाने वाले ब्लॉक-कैच ब्लॉक
• सामान्य नाम के साथ कार्य process, data, change, rework,modify
• 100 लाइनों में छह या सात अलग-अलग ब्रेसिंग स्टाइल

एक मैं बस पाया:

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

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

Comments

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

— फिनकेक

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

— मॉर्गन हेरलॉकर

@ प्लम प्लम - आप क्या उदाहरण दे सकते हैं? आमतौर पर कई नेस्टेड का विकल्प अगर इसे (कई) तरीकों से बाहर निकालना है। जूनियर डेवलपर्स इसे से बचने के लिए करते हैं, हालांकि यह अगर की तुलना में कम वांछनीय है; लेकिन आमतौर पर जब दबाया जाता है तो वे कहते हैं "अगर यह कम लाइनों में है"। यह OOP में किसी को आश्वस्त करने के लिए कदम उठाता है और उन्हें याद दिलाता है कि कम लाइनें! = बेहतर कोड।

— STW

@STW यह एक अच्छा बिंदु है, हालांकि, मैं कहूंगा कि यह निर्भर करता है कि घोंसला कितना गहरा है। मैं निश्चित रूप से इस बात से सहमत हूं कि कुछ और अधिक तो तीन घोंसले गहरे अक्सर रिफ्लेक्टरिंग की आवश्यकता होती है, क्योंकि इसके बाल बहुत सुंदर हो रहे हैं। हालांकि, बीमा उद्धरण एक अच्छा उदाहरण है जहां मल्टी-नेस्टिंग वास्तव में वास्तविक दुनिया को काफी अच्छी तरह से मॉडल कर सकता है। कुछ दरों / प्रीमियमों के अपवादों के साथ, मैनुअल शाब्दिक रूप से कुछ पढ़ेगा "यदि यह एक संपत्ति है और अगर इसकी न्यूनतम दर 5.6 से कम है और यदि यह नेकां में है और यदि परिसर में नाव है, तो ऐसा करें और इस तरह के। " कई अन्य विकल्पों के साथ।

— मॉर्गन हेरलॉकर

@ जोश, अगर "वे" सहकर्मी हैं तो मैं इस बात पर विचार करूंगा कि आपने "हम" क्यों नहीं कहा ...

Answer 2

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

मैं एक लाल झंडे के रूप में टिप्पणियों की कमी भी गिना करता था, लेकिन हाल ही में बहुत सारे अच्छे कोड पर काम किया है जिसमें कोई टिप्पणी नहीं है जो मैंने वापस ले ली है।

Comments

+1: मैंने सहकर्मी से कुछ कोड देखे, जिन्होंने खुद को एक लिनक्स विशेषज्ञ के रूप में बताया, जिन्होंने एक साधारण फंक्शनिंग एप्लिकेशन को एक लंबे फ़ंक्शन के रूप में लिखा, पूरी बात मुख्य और अधिक से अधिक ()। ओह।

— KFro

@ केफ्रो, यह लूप अन्रॉलिंग है। Thats क्या संकलक हर समय :) बहुत कुशल!

@ थोरबॉर्न: कभी-कभी, आपको कंपाइलर की थोड़ी मदद करनी होगी; आखिरकार, आप स्मार्ट इंसान हैं और वह सिर्फ एक गूंगा कंप्यूटर है।

— यतीमा २

एक अन्य कारण जो मैंने देखा है: सलाहकार को सुविधा को जल्द से जल्द लागू करने के लिए भुगतान किया गया था (इसीलिए परीक्षण और प्रलेखन भी गायब हैं, निश्चित रूप से)। कॉपी / पेस्ट यह सोचने से तेज है कि चीजों को सही कैसे किया जाए।

— लेनीप्रोग्रामर्स

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

— स्टीव 314

Answer 3

कोड जो यह दिखाने की कोशिश करता है कि प्रोग्रामर कितना चालाक है, इस तथ्य के बावजूद कि इसमें कोई वास्तविक मूल्य नहीं है:

x ^= y ^= x ^= y;

Comments

वाह, यह sooo से अधिक पठनीय हैswap(x, y);

— JBRWilkinson

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

— एकलकरण

वैसे, यह कोड सी और सी ++ में अपरिभाषित है क्योंकि एक हस्तक्षेप अनुक्रम बिंदु के बिना कई परिवर्तन।

— फ्रेडओवरफ्लो

कि को देखते हुए, केवल एक चीज है जो मन में आया इमोटिकॉन थे:^_^

— Darien

Answer 4

• 20,000 (अतिशयोक्ति) लाइन फ़ंक्शन। किसी भी फंक्शन जो एक दो से ज्यादा स्क्रीन लेता है, उन्हें री-फैक्टरिंग की जरूरत होती है।

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

• गैर-वर्णनात्मक, गैर-तुच्छ चर या बहुत अधिक तुच्छ गैर-वर्णनात्मक चर। ये वास्तव में एक पहेली बन रही है।

Comments

जब भी संभव हो मैं फ़ंक्शन को 1 स्क्रीन तक सीमित करता हूं।

— मैट डीट्रोलियो

1 स्क्रीन भी एक खिंचाव है। मैं 10 या तो लाइनों के बाद गंदा लग रहा है।

— ब्रायन रोवे

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

— दान रे

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

— डोमिनिक मैकडोनेल

@Dominic, @ Péter, मुझे लगता है कि हम तीनों वास्तव में एक ही बात कह रहे हैं। जब छोटे समारोह में कारक कोड का एक अच्छा कारण है, तो मैं इसके लिए हूं। फंक्शन डिज़ाइन में लघुता के लिए मैं जिसे अस्वीकार कर रहा हूं वह है लघुता । तुम्हें पता है, एक कॉल स्टैक है जो इसे होने की तुलना में तीन गुना अधिक है, लेकिन कम से कम उन कार्यों को कम कर रहे हैं। मैं एक लंबा कार्य करना चाहता हूं जो एक बात को अच्छी तरह से करता है और स्पष्ट रूप से एक दर्जन जंजीर कार्यों के माध्यम से निष्पादन पथ का पीछा करता है जो प्रत्येक केवल पिछले एक से बुलाए जाते हैं।

— डैन रे

Answer 5

{ Let it Leak, people have good enough computers to cope these days }

Whats बदतर यह है कि एक वाणिज्यिक पुस्तकालय से है!

Comments

यह खतरे की घंटी नहीं बजती है। यह व्यावहारिक रूप से आपको पैरों के बीच मारता है।

— स्टीवन एवर्स

बेटी मैथ की दीवानी है। कौन परवाह करता है, कम से कम वह मोटे नहीं हो जाएगा। :: आह ::

— इवान प्लाइस

जब मैं मुसीबत के समय खुद को पाता हूं, तो मां बंटू मेरे पास आती है। ज्ञान के शब्द बोलते हुए, इसे लीक होने दो। LET IT LEAK .. LET IT LEAK। इसे प्राप्त करें ओह ओह इसे प्राप्त करें। अगर यह सिर्फ एक बार लीक होता है, तो यह एक लीकेज नहीं है। (यदि आप इसे दूर पढ़ते हैं, तो +1)। मुझे वास्तव में डिकैफ़ पर विचार करने की आवश्यकता है।

— टिम पोस्ट

"जैसे ही समय सीमा तेजी से

— आगे बढ़ती है

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

— मार्टिन बेकेट

Answer 6

टिप्पणियाँ जो इतनी क्रियात्मक हैं कि अगर कोई अंग्रेजी संकलक थे, तो यह संकलन और पूरी तरह से चलेगा, फिर भी कुछ भी वर्णन नहीं करता है जो कोड नहीं करता है।

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

इसके अलावा, कुछ बुनियादी दिशानिर्देशों का पालन करने वाले कोड पर टिप्पणी की जा सकती है:

//Set the age of the user to 13.
a = 13;

Comments

वहाँ है, इसे कहा जाता है COBOL :-)

— गयूस

दूसरा मामला सबसे बुरा नहीं है। सबसे खराब है: / * उपयोगकर्ता की आयु 13 * / a = 18 पर सेट करें;

— फीलो

@PhiLho - नहीं, और भी बदतर है जब है /से */याद आ रही है, इसलिए अगले के अंत करने के लिए सभी कोड */नजरअंदाज कर दिया है। सौभाग्य से, वाक्य रचना हाइलाइटिंग इन दिनों उस तरह का दुर्लभ बनाता है।

— स्टीव 314

फिर से बदतर, auser_age के लिए? वास्तव में?

— ग्लासस

मैं पिछले नियोक्ता पर एक कोड मानक डॉक्टर बनाए रखता था, जिसमें से एक अनुभाग उपयुक्त टिप्पणी करता था। मेरा पसंदीदा उदाहरण MSDN से था:i = i + 1; //increment i

— माइकल इट्ज़ो

Answer 7

कोड जो संकलित होने पर चेतावनी उत्पन्न करता है।

Comments

मेकफाइल / प्रोजेक्ट में 'सभी चेतावनियों के रूप में एरर्स कंपाइलर विकल्प' को जोड़ने के लिए एक उम्मीदवार है।

— JBRWilkinson

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

— री मियासका

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

— टिम पोस्ट

मैं (unsigned int)सौम्य चेतावनियों के साथ अपनी चेतावनी / त्रुटि सूचियों को अव्यवस्थित करने के बजाय अपने कोड को लगभग एक-दूसरे के साथ जोड़ना चाहूंगा । मुझे चेतावनी सूची के लिए एक अंधे स्थान बनने से नफरत होगी। यह भी एक PITA अन्य लोगों के लिए कारण बताते हुए आपको एक चेतावनी को अनदेखा कर रहे तुलना में यह कारण है कि आप प्राकृतिक की एक डाली कर रहे हैं समझाने के लिए है की बहुत कुछ है intsकरने के लिए unsigned ints।

— री मियाँसाक

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

— डोनल फैलो

Answer 8

वर्णनात्मक नाम रखने के बजाय नाम में संख्या के साथ कार्य :

void doSomething()
{
}

void doSomething2()
{
}

कृपया, फ़ंक्शन के नामों को कुछ अर्थ दें! यदि doSomething और doSomething2 समान कार्य करते हैं, तो फ़ंक्शन नाम का उपयोग करें जो अंतर को अलग करता है। यदि doSomething2 doSomething से कार्यक्षमता का ब्रेक-आउट है, तो इसे अपनी कार्यक्षमता के लिए नाम दें।

Comments

इसी तरह @Parm for SQL

— डेव

+1 - दर्ज करें mshtml- इससे मेरी आँखें टूट जाती हैं :(

— काइल रोज़ेंडो

इसका अपवाद जीयूआई कोड होगा। उदाहरण के लिए, यदि एक घोंघा-मेल फॉर्म में दो पते थे; एड्रेस 1 और एड्रेस 2 एड्रेस और अल्टरनेटिव से ज्यादा वाजिब है। स्थैतिक लेबल जो केवल स्थैतिक हैं, एक उचित अपवाद भी हैं।

— इवान प्लाइस

@ इवान - काफी उचित है, हालांकि मैं कार्यक्षमता में भेद कर रहा था।

— साने

+1 - मैंने इसे छद्म संस्करण नियंत्रण विधि के रूप में भी देखा है।

— ईज़ी हार्ट

Answer 9

मैजिक नंबर या मैजिक स्ट्रिंग्स।

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

Comments

वास्तव में दूसरे दो के साथ बुरा नहीं है, कम से कम छूट को समझाया गया है, और "अतिदेय" सहज है। 200दूसरी ओर ...

— Tarka

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

— JohnFx

+1 मैंने एक समस्या को डीबग करने में बहुत समय बिताया, जो एक लाइन 'टाइमआउट = 15' के कारण हुई थी। एक कार्यक्रम में दफनाया गया।

— ऐब्यूरीहोड्स

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

— बेन ली

Answer 10

• शायद सबसे बुरा नहीं है लेकिन स्पष्ट रूप से कार्यान्वयनकर्ताओं के स्तर को दर्शाता है:

  if(something == true) 

• यदि किसी भाषा में लूप या इटरेटर का निर्माण होता है, तो थोड़ी देर के लूप का उपयोग करने से भाषा की समझ के कार्यान्वयन के स्तर का भी पता चलता है:

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.

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

Answer 11

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

Comments

मुझे पता है कि कुछ लोगों ने सीखा कि हर विधि में केवल एक returnकथन होना चाहिए , लेकिन जब यह 6+ स्तरों का कारण बनता है, तो मुझे लगता है कि यह अच्छा करने की तुलना में कहीं अधिक नुकसान कर रहा है।

— डेरेन

Answer 12

जब किसी छात्र के कार्यक्रम की ग्रेडिंग की जाती है, तो मैं कभी-कभी "पलक" में बता सकता हूं। ये तात्कालिक सुराग हैं:

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

शायद ही कभी मेरा पहला इंप्रेशन गलत होता है, और ये चेतावनी घंटियाँ लगभग 95% सही होती हैं । एक अपवाद के लिए, भाषा में एक नया छात्र एक अलग प्रोग्रामिंग भाषा से एक शैली का उपयोग कर रहा था। दूसरी भाषा के मुहावरे में अपनी शैली को खोदना और फिर से पढ़ना मेरे लिए खतरे की घंटी है, और छात्र ने तब इसका पूरा श्रेय लिया। लेकिन ऐसे अपवाद दुर्लभ हैं।

अधिक उन्नत कोड पर विचार करते समय, ये मेरी अन्य चेतावनी हैं:

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

शैली के संदर्भ में, मैं आमतौर पर देखना पसंद नहीं करता:

• Javadoc टिप्पणी करता है जो केवल कोड को प्रतिध्वनित करता है

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

Comments

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

— निक टी

मैं उन कक्षाओं के साथ कुछ भी गलत नहीं देखता जो केवल डेटा एकत्र करते हैं - अर्थात, संरचना। डेटा ट्रांसफर ऑब्जेक्ट्स (DTO) क्या हैं और यह कहने की तुलना में कोड को बहुत अधिक पठनीय बना सकता है, उदाहरण के लिए, किसी विधि में 20 मापदंडों से गुजरना।

— नेमी

स्ट्रक्चर्स के बारे में आपकी टिप्पणी हाजिर है। यह ठीक है जब डेटा अपने सबसे कच्चे रूप में है और किसी भी तरह से संशोधित नहीं किया जाएगा। लेकिन समय का 95% आपको डेटा पर प्रारूपित / संचालित करने के लिए कक्षा में कुछ कार्य होने चाहिए। मुझे बस अपने कुछ कोड याद थे जो अनिवार्य रूप से उस पैटर्न का उपयोग करते हैं और उन पर सुधार किया जाना चाहिए।

— असंतुष्ट

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

— डीन हार्डिंग

मैं एक विधि की घोषणा रेखा की तलाश में हूं जो शरीर के सापेक्ष बहुत दूर है। यह एक संकेत है जिसे वे किसी और की फ़ाइल से कॉपी-पेस्ट करते हैं।

— बैरी ब्राउन

Answer 13

व्यक्तिगत पसंदीदा / पालतू जानवर: आईडीई ने ऐसे नाम उत्पन्न किए हैं जो कॉमेडी करते हैं। यदि TextBox1 आपके सिस्टम में एक प्रमुख और महत्वपूर्ण चर है, तो आपको कोड रिव्यू आने वाली एक और चीज़ मिल गई है।

Answer 14

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

Answer 15

बहुत सारे लोगों ने उल्लेख किया है:

//TODO: [something not implemented]

जबकि मैं चाहता हूं कि सामान को लागू किया गया था, कम से कम उन्होंने एक नोट बनाया। मुझे लगता है कि बदतर है:

//TODO: [something that is already implemented]

टोडो बेकार और भ्रमित हैं यदि आप उन्हें हटाने के लिए कभी परेशान नहीं करते हैं!

Comments

मैं अभी-अभी अपने रिलीज़ प्रोडक्ट में सभी TODOs की रिपोर्ट तैयार करने के साथ-साथ उन्हें निपटाने की योजना बनाने के बहाने भी गया। लगभग आधा निकला अप्रचलित।

— एएसएचली

-1 TODO टिप्पणियों का उपयोग MS Visual Studio में उस परियोजना के कुछ हिस्सों को ट्रैक करने के लिए किया जाता है जिन्हें अभी भी काम की आवश्यकता है। IE, IDE एक सूची रखता है जो TODOs को ट्रैक करता है ताकि आप आसानी से उन पर क्लिक कर सकें और सीधे उस लाइन पर लाया जा सके जिस पर TODO चलता है। मैं इसके बजाय TODOs को स्पष्ट रूप से देखने के लिए देखूंगा कि अभी भी क्या काम करने की आवश्यकता है। Dotnetperls.com/todo देखें ।

— इवान प्लाइस

@ ईवन प्लास: वाह, आपका मतलब है कि जब आप कुछ लागू करते हैं तो वीएस आईडीई पहचानता है और //TODOटिप्पणी को हटा देता है ? बहुत बढ़िया!

— JBRWilkinson

@Prof प्लम क्यों न केवल एक नीति बनाई जाए जहां TODO के लिए जिम्मेदार व्यक्ति टिप्पणी में अपना नाम डालता है। इस तरह, अगर वहाँ कुछ बचे हुए हैं

— इवान प्लाइस

से बेहतर योजना // TODO , अपने बग ट्रैकर का उपयोग करें, यही इसके लिए है!

— एकलकरण

Answer 16

एक विधि जो मुझे यह सब पढ़ने के लिए नीचे स्क्रॉल करने की आवश्यकता है।

Comments

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

— बिली ओनली

एक कंबल बयान के रूप में तब मैं असहमत हूं, लगातार समय बर्बाद करने से समय बर्बाद हो रहा है ताकि सब कुछ इस तरह के स्व-लगाए गए नियम के अनुरूप हो।

— अनाम टाइप

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

— ब्रैडब

मैं नीचे स्क्रॉल करने की तुलना में स्क्रॉलिंग पर अधिक नाराज हूं। व्हाट्सप "मुक्त" है।

— साने

मैं इसके बजाय स्क्रॉल करना चाहता हूं कि कोड क्या कर रहा है यह पता लगाने के लिए फ़ाइल (या कई फाइलों) पर छोड़ देना चाहिए।

— TMN

Answer 17

विधि नामों में निष्कर्ष:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

स्पष्टता: इस खतरे की घंटी बजने का कारण यह है कि यह इंगित करता है कि विधि एकल जिम्मेदारी सिद्धांत का उल्लंघन करती है ।

Comments

हम्मम ... यदि फ़ंक्शन नाम सही ढंग से परिभाषित करता है कि फ़ंक्शन क्या करता है, तो मैं असहमत हूं। यदि विधि दो अलग-अलग चीजें करती है जो अलग करना बेहतर होगा, तो मैं संदर्भ के आधार पर सहमत हो सकता हूं।

— विनको द सैन

यही तो बात है। संयुग्मन का अर्थ है कि यह बहुत संभावना है कि यह एक से अधिक काम करता है। सवाल के अनुसार यह सिर्फ कुछ है जो मेरी जागरूकता को बढ़ाता है कि कुछ गलत हो सकता है।

— JohnFx

अब क्या होगा अगर आपको एक कर्मचारी को जोड़ना होगा और कई जगहों पर उनके पे-अपडेट को अपडेट करना होगा? यदि उस विधि में दो विधि कॉल ( addEmployee(); updatePayrate();) हैं, तो मुझे नहीं लगता कि यह कोई समस्या है।

— मैट ग्रैंडे

Answer 18

एक वाणिज्यिक, बंद-स्रोत कार्यक्रम में स्पष्ट रूप से GPL'd स्रोत कोड को जोड़ना।

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

Comments

जबकि आपकी बात उत्कृष्ट है, आपका लहजा अनावश्यक है।

— JBRWilkinson

@JBRWilkinson: धन्यवाद, आप सही हैं। सभी को मेरी क्षमायाचना।

— बॉब मर्फी

मुझे लगता है कि आपकी हेडिंग को फिर से लिखने की जरूरत है। GPL'd सोर्स कोड से स्टेटिक और डायनामिकली दोनों तरह से लिंक करना GPL का उल्लंघन है ...

— Gavin Coates

अच्छे अंक। मैंने पूरी पोस्ट फिर से लिखी है। सभी को धन्यवाद।

— बॉब मर्फी

Answer 19

भाषा अज्ञेय:

• TODO: not implemented
• int function(...) { return -1; } ("लागू नहीं" के रूप में ही)
• एक गैर-असाधारण कारण के लिए एक अपवाद फेंकना।
• दुरुपयोग या असंगत उपयोग 0, -1या nullअसाधारण वापसी मूल्यों के रूप में।
• एक ठोस टिप्पणी के बिना यह कहते हुए कि यह कभी असफल क्यों नहीं होना चाहिए।

भाषा विशिष्ट (C ++):

• लोअरकेस में C ++ मैक्रोज़।
• स्टेटिक या ग्लोबल C ++ वैरिएबल।
• Uninitialized या अप्रयुक्त चर।
• कोई भी array newजो जाहिरा तौर पर RAII- सुरक्षित नहीं है।
• सरणी या पॉइंटर का कोई भी उपयोग जो स्पष्ट रूप से सीमा-सुरक्षित नहीं है। इसमें शामिल हैं printf।
• किसी सरणी के अन-इनिशियलाइज्ड हिस्से का कोई उपयोग।

Microsoft C ++ विशिष्ट:

• किसी भी पहचानकर्ता के नाम जो पहले से ही Microsoft SDK हेडर फ़ाइलों में से किसी एक मैक्रो से टकराते हैं।
• सामान्य तौर पर, Win32 एपीआई का कोई भी उपयोग खतरे की घंटी का एक बड़ा स्रोत है। हमेशा MSDN खुला है, और जब भी संदेह में तर्क / वापसी मूल्य परिभाषाएँ देखें। (संपादित)

C ++ / OOP विशिष्ट:

• कार्यान्वयन (ठोस वर्ग) वंशानुक्रम जहां माता-पिता वर्ग में आभासी और गैर-आभासी दोनों तरीके हैं, बिना स्पष्ट स्पष्ट वैचारिक भेद के कि क्या होना चाहिए / आभासी नहीं होना चाहिए।

Comments

// TODO: इस उत्तर पर टिप्पणी करें

— johnc

मुझे लगता है कि "भाषा अज्ञेय" का अर्थ "C / C ++ / Java" है?

— इनामाथी

+1 "एक गैर-असाधारण कारण के लिए एक अपवाद फेंकना" अधिक सहमत नहीं हो सकता है!

— billy.bob

@ इमानाथी - TODO टिप्पणियाँ, कार्य स्टब्स, अपवाद दुरुपयोग, शून्य / अशक्त / खाली शब्दार्थ की उलझन और व्यर्थ संन्यास जाँच सभी अनिवार्य / OOP भाषाओं और कुछ हद तक सामान्य रूप से सभी प्रोग्रामिंग भाषाओं में निहित हैं।

— री मियासका

मुझे विश्वास है कि लोअर केस में सी पूर्वप्रक्रमक मैक्रो हैं ठीक है, लेकिन केवल तभी जब वे अपने तर्कों केवल एक बार का मूल्यांकन करने और केवल एक ही बयान में परिणाम।

— जो डी

Answer 20

विचित्र इंडेंटेशन स्टाइल।

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

Comments

या बस एक संकेत है कि वे एक अत्यधिक बेशकीमती व्यक्तिवादी प्रतिभा हैं जो होमोगोनाइज्ड कोडिंग प्रथाओं के जाल में नहीं फंसते हैं जो "सर्वोत्तम प्रथाओं" से संबंधित नहीं हैं।

— अनाम टाइप

मुझे आशा है कि आप व्यंग्यात्मक हैं। अगर कोई ऐसे असामान्य तरीके से कोडिंग कर रहा है, तो उसे अलार्म की घंटी बजानी चाहिए। वे जितना चाहें उतना कलात्मक हो सकते हैं, लेकिन फिर भी ... खतरे की घंटी।

— केन

कुछ हद तक असामान्य शैली है (मेरा मानना ​​है कि इसे यूट्रेक्ट शैली कहा जाता है) जो मुझे लगता है कि हास्केल / एमएल / एफ # के बाहर बेहद असामान्य होने के बावजूद काफी उपयोगी है। नीचे स्क्रॉल करें "मॉड्यूल आकृतियाँ": learnyouahaskell.com/making-our-own-types-and-typeclasses । इस शैली के बारे में क्या अच्छा है कि आपको नया जोड़ने के लिए पूर्ववर्ती रेखा पर सीमांकक को संशोधित करने की आवश्यकता नहीं है - जिसे मैं अक्सर करना भूल जाता हूं।

— री मियासका

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

— रयान रीच

@RyanReich अजीब, सात साल बाद, और मैं अभी भी इसे पसंद करता हूं। मैं सहमत हूँ, यद्यपि; अपने सभी वाक्यात्मक अजीबता और विफलताओं के लिए, F # भी आइटमों को एक नई पंक्ति और इंडेंटेशन (ज्यादातर मामलों में) द्वारा सीमांकित करने की अनुमति देता है, जो स्पष्ट कोड के लिए बनाता है।

— री मियासाका

Answer 21

बहुत से पाठ-खंडों का उपयोग करने के बजाए enums या वैश्विक रूप से परिभाषित चर के बजाय।

अच्छा नही:

if (itemType == "Student") { ... }

बेहतर:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

श्रेष्ठ:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

Comments

या सबसे अच्छा: बहुरूपता का उपयोग करें।

— 7

Answer 22

कमजोर टाइप किए गए पैरामीटर या तरीकों पर मान लौटाएं।

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

Comments

+1: मुझे कुछ "REST" वेब सेवाओं के साथ काम करना है जो छद्म-HTML तालिकाओं के रूप में सब कुछ लौटाती हैं, यहां तक ​​कि जहां आप उन चीजों में गुजरते हैं जो एक स्पष्ट वाक्यविन्यास त्रुटि है। अधिकृत नहीं? इनपुट पूरा जंक? क्षमता से अधिक सर्वर? 200 (प्लस एक कॉलम, एक पंक्ति तालिका में एक भयानक प्रारूप में एक संदेश)। AAaaaaaaaargh!

— डोनल फैलो

Answer 23

• कई टर्नरी ऑपरेटर आपस में टकराते हैं, इसलिए एक if...elseब्लॉक से मिलता जुलता है , यह एक if...else if...[...]...elseब्लॉक बन जाता है
• बिना अंडरस्कोर या कैमलकास्टिंग के साथ लंबे चर नाम। मेरे द्वारा खींचे गए कुछ कोड से उदाहरण:$lesseeloginaccountservice
• एक फ़ाइल में कोड की सैकड़ों लाइनें, जिसमें कोई टिप्पणी नहीं है, और कोड बहुत गैर-स्पष्ट है
• अत्यधिक जटिल ifकथन। कोड से उदाहरण: if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))जिसे मैंने नीचे दबा दिया थाif ($lessee_obj == null)

Answer 24

कोड गंध: सर्वोत्तम प्रथाओं का पालन नहीं करना

इस तरह की बात मुझे हमेशा परेशान करती है क्योंकि ट्रूइज़म है कि हर कोई सोचता है कि वे एक औसत ड्राइवर हैं।

यहाँ एक समाचार के लिए फ़्लैश है: दुनिया की आबादी का 50% औसत खुफिया से नीचे है। ठीक है, तो कुछ लोगों के पास औसत बुद्धि होगी, लेकिन चलो अचार नहीं मिला। इसके अलावा, एक पक्ष मूर्खता को प्रभावित करता है आप अपनी मूर्खता को नहीं पहचान सकते हैं! यदि आप इन कथनों को जोड़ते हैं तो चीजें इतनी अच्छी नहीं लगतीं।

कोड को देखते समय कौन सी चीजें तुरंत खतरे की घंटी बजाती हैं?

कई अच्छी चीजों का उल्लेख किया गया है, और सामान्य तौर पर ऐसा लगता है कि सर्वोत्तम प्रथाओं का पालन ​​नहीं करना एक कोड गंध है।

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

सबसे अच्छा अभ्यास का एक उदाहरण प्रत्येक if- ब्लॉक के साथ curlies का उपयोग किया जा सकता है, भले ही इसमें केवल एक ही पंक्ति हो:

if (something) {
    // whatever
}

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

याद रखें: "क्योंकि यह सबसे अच्छा अभ्यास है" सवाल का कोई स्वीकार्य उत्तर नहीं है "आप ऐसा क्यों कर रहे हैं?" यदि आप यह स्पष्ट नहीं कर सकते हैं कि कोई चीज़ सबसे अच्छा अभ्यास क्यों है, तो यह सबसे अच्छा अभ्यास नहीं है, यह एक अंधविश्वास है।

Comments

यह पांडित्य हो सकता है, लेकिन मुझे लगता है कि यह मायने रखता है कि आप किस औसत को चुनते हैं। जैसा कि मैंने इसे समझा, दुनिया की आबादी का 50% औसत बुद्धि (परिभाषा के अनुसार) से नीचे है; लेकिन अन्य औसत उसी तरह से काम नहीं करते हैं। उदाहरण के लिए जनसंख्या (1, 1, 1, 5) को लें, जिसका अंकगणितीय माध्य 2 है

— राजहंस

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

— इवान प्लाइस

@ इवान: हाँ, आप सही कह रहे हैं। मैंने इसके बारे में थोड़ा और जोड़ा, आशा है कि इससे मदद मिलेगी।

— वेटल

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

— डैन डायर

बहुत अच्छी टिप्पणी, डैन! मैंने उत्तर में दो अंतिम पंक्तियाँ जोड़ीं।

— वेटले

Answer 25

टिप्पणियाँ जो कहती हैं "यह इसलिए है क्योंकि फ्रोज़ सबसिस्टम का डिज़ाइन पूरी तरह से बोर्क है।"

यह एक पूरे पैराग्राफ पर चलते हैं।

वे बताते हैं कि निम्नलिखित रिफ्लेक्टर होने की आवश्यकता है।

लेकिन ऐसा नहीं किया।

अब, उन्हें बताया जा सकता था कि वे समय या क्षमता के मुद्दों के कारण अपने बॉस द्वारा इसे बदल नहीं सकते थे, लेकिन शायद यह लोगों के क्षुद्र होने के कारण था।

अगर एक पर्यवेक्षक सोचता है कि j.random। प्रोग्रामर रीफैक्टरिंग नहीं कर सकता है, तो सुपरवाइजर को करना चाहिए।

वैसे भी ऐसा होता है, मुझे पता है कि कोड एक विभाजित टीम द्वारा लिखा गया था, संभव शक्ति की राजनीति के साथ, और उन्होंने उपप्रकार डिजाइनों को रिफैक्ट नहीं किया।

सच्ची कहानी। यह आपके साथ हो सकता था।

Answer 26

क्या कोई ऐसे उदाहरण के बारे में सोच सकता है जहां कोड वैध रूप से किसी फ़ाइल को पूर्ण पथ द्वारा संदर्भित करना चाहिए?

Comments

XML स्कीमा गिनती?

— निक टी

सिस्टम कॉन्फ़िगरेशन फ़ाइलें। आमतौर पर ./configure द्वारा सेट किया जाना चाहिए, लेकिन यहां तक ​​कि कहीं एक डिफ़ॉल्ट मूल्य की आवश्यकता है।

— eswald

/dev/nullऔर दोस्तों ठीक है। लेकिन यहां तक ​​कि चीजों की तरह /bin/bashसंदिग्ध हैं - क्या होगा यदि आप एक कुछ कुकी प्रणाली है जो है /usr/bin/bash?

— टॉम एंडरसन

JAX-WS टूल्स (JBossWS और Metro, कम से कम) द्वारा जनरेट किए गए वेब सेवा क्लाइंट कोड में WSDL फ़ाइल (दो बार!) के लिए एक कठोर पूर्ण पथ शामिल है। जो शायद कुछ बेतहाशा अनुचित है जैसे /home/tom/dev/randomhacking/thing.wsdl। यह आपराधिक रूप से पागल है कि यह डिफ़ॉल्ट व्यवहार है।

— टॉम एंडरसन

के बारे में /dev/null: मुझे आदत है, जब क्षुधा और काम के तहत रखने के लिए खिड़कियों पर विकसित करना c:\dev। किसी तरह, एक फ़ोल्डर nullहमेशा उस फ़ोल्डर के अंदर स्वचालित रूप से बनाया जाता है। मैं कसम खाता हूं कि मुझे नहीं पता कि कौन ऐसा करता है। (मेरे पसंदीदा कीड़े / सुविधाओं में से एक)

— शॉन पैट्रिक फ्लोयड

Answer 27

सामान्य अपवादों को पकड़ना:

try {

 ...

} catch {
}

या

try {

 ...

} catch (Exception ex) {
}

क्षेत्र अति प्रयोग

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

Comments

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

— कैश

+1 'कैच एंड थ्रो अप अपवाद' उदाहरण के लिए। यदि आप अपवाद के साथ कुछ नहीं कर रहे हैं, तो इसे न पकड़ें। बहुत कम से कम, इसे लॉग इन करें। बहुत कम से कम, एक टिप्पणी में यह बताते हुए कि सभी अपवादों को पकड़ना और कोड में उस बिंदु पर आगे बढ़ना क्यों ठीक है।

— ईज़ी हार्ट

Answer 28

क्लास नामकरण परंपराएं जो अमूर्त की खराब समझ को प्रदर्शित करती हैं, जो वे बनाने का प्रयास कर रहे हैं। या कि एक अमूर्तता को बिल्कुल भी परिभाषित नहीं करते हैं।

एक चरम उदाहरण एक वीबी कक्षा में ध्यान में आता है जिसे मैंने एक बार देखा था जिसका शीर्षक Dataथा और पहली फ़ाइल में 30,000+ लाइनें लंबी थी । यह कम से कम आधा दर्जन अन्य फाइलों में विभाजित एक आंशिक वर्ग था। अधिकांश विधियाँ संग्रहीत नामों के आसपास रैपर थीं जैसे कि नाम के साथ FindXByYWithZ()।

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

Answer 29

ऐसे कार्य जो भाषा की बुनियादी कार्यक्षमता को फिर से लागू करते हैं। उदाहरण के लिए, यदि आप कभी भी स्ट्रिंग के ".length" संपत्ति के लिए कॉल के बजाय जावास्क्रिप्ट में "getStringLength ()" विधि देखते हैं, तो आप जानते हैं कि आप मुसीबत में हैं।

Answer 30

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

बेशक प्रलेखन के किसी भी प्रकार और सामयिक नेस्टेड बिना #defineरों

Comments

मैंने कल इस "पैटर्न" को कल ही देखा है ... उत्पादन कोड में ... और इससे भी बदतर ... सी ++ उत्पादन कोड में: - /

— ओलिवर वीलर