कोड में लाइनों की संख्या को कम करना कितना महत्वपूर्ण है?

85

मैं एक सॉफ्टवेयर डेवलपर हूं जो J2SE (कोर जावा) पर काम करता है।
अक्सर हमारे कोड रिव्यू के दौरान हमें अपने कोड में लाइनों की संख्या कम करने के लिए कहा जाता है।

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

आपको क्या लगता है कि चीजों को करने का सही तरीका क्या है?
यदि LOC (कोड की लाइनें) एक छोटी संख्या है, तो यह कोड को कैसे प्रभावित करता है? यदि LOC एक बड़ी संख्या है, तो यह कोड को कैसे प्रभावित करता है?

वेबसाइट से उदाहरण: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

वी.एस.

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

— अंकित
स्रोत

63

मैं किसी भी जावा फाइल को कोड की एक लाइन में बदल सकता हूं ( s/\n/ /g) इसका मतलब यह नहीं है कि यह दूर से पढ़ने योग्य भी होगा

— शाफ़्ट फ्रीक

6

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

— जेफ़ओ

29

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

— डैनियल बी

3

कभी अपने कमरे को साफ करो, तो तुम्हारी माँ अंदर आती है और कहती है कि "यह साफ नहीं है" और 10 चीजें बताती हैं जिन्हें आपने दूर नहीं किया था। मूल रूप से वे वही हैं जो आपको कोड समीक्षा में बता रहे हैं।

— रिएक्टगुलर

11

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

— डेनियल बी

75

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

SLOC को मापना (जो प्रभावी रूप से आपकी समीक्षा कर रहा है), SLOC को महत्वपूर्ण बनाता है .... क्या SLOC महत्वपूर्ण है? - बिल्कुल नहीं, कभी नहीं किया गया है (बाहर की प्रोग्रामिंग प्रोग्रामिंग प्रतियोगिता ), एक वाणिज्यिक संगठन में कभी नहीं होगा।

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

— मैट्नज़
स्रोत

33

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

— डेनियल बी

3

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

— क्लैंड्री

2

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

— एडविन बक

1

@CLandry: एक पृष्ठ पर इसे फिट करके संदर्भ बनाए रखना SLOC को कम करने का एक बहुत बुरा कारण है। निश्चित रूप से संदर्भ को बनाए रखना आसान है यदि कोड अच्छी तरह से बाहर रखा गया है और पढ़ने में आसान है। - क्या एक "पृष्ठ" 2500 या 1000 पिक्सेल? मेरे पास पोर्ट्रेट में 2 * 30 "के मॉनिटर्स हैं, फिर भी कभी-कभी एक लैपटॉप पर विकसित होते हैं।

— मैटनज़

4

LOC === कीड़े दिखाने वाले अध्ययन (रेफरी) एक समय में एक दर्जन हैं। इसका एक जाना माना और स्वीकृत तथ्य है। जो नहीं दिखाया गया है (मेरी जानकारी में) वह है (Ref b) "कोड बेस में = LOC को घटाएं === उस कोड बेस में कीड़े कम करें"। दावा करने के लिए एक्सट्रैपलेटिंग (रेफरी) (रेफ बी) अवैज्ञानिक है। एक पेपर प्रकाशित करना जो साबित करता है या संबंध को बाधित करता है।

— मटनज़

84

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

यहाँ तारांकन है, हालांकि। यह विचार में कोड की लाइनों की वास्तविक संख्या के बारे में नहीं है क्योंकि आप कुछ के साथ लाइनों की संख्या को कम कर सकते हैं:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

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

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

— एरिक डायट्रिच
स्रोत

4

सहमत - बयान की संख्या को कम करना, एक सीमा तक उपयोगी हो सकता है, हालांकि, यदि कोड समीक्षा बयानों की संख्या को कम करना चाहती है, तो क्या वे "कम बयानों की संख्या" के बजाय "कम संख्या की रेखाओं" को नहीं कहेंगे। कोड "।

— मैट्नज

1

यदि उन्हें पांडित्य हो रहा है तो केवल @mattnz।

— डान नीली

2

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

— डैनियल एए पल्सेमेकर

13

+1 विनोदी रूप से लंबे फ़ंक्शन कॉल श्रृंखला के लिए, और उसके बाद डरपोक डबल ब्रैकेट violations()।

— जो जेड

5

100% +1, इतने सारे लोग कोड के प्रत्येक अतिरिक्त बिट कोड के परिणामों को नहीं समझते हैं, यह कुछ ऐसा है जिसके बारे में लोगों को वास्तव में जानने की आवश्यकता है।

— जिमी हॉफ

32

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

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

जैसे केन थॉम्पसन ने एक बार कहा था: मेरे सबसे उत्पादक दिनों में से एक कोड की 1000 लाइनों को फेंक रहा था ।

— Xion
स्रोत

21

मैं "आपके कोड में स्पष्टता होने की स्थिति से सहमत हूं, भले ही इसका मतलब है कि लाइनों की संख्या बढ़ाना।"

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

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

— jhewlett
स्रोत

12

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

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

मेरे लिए पूरी तरह से अस्वीकार्य होगा, हालांकि, मैंने पाया कि सभी कंपनियों को मौजूदा कोड में परिवर्तन करना चाहिए:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

सेवा:

value.prop =  boolean ? option1 : option2;

एक उत्कृष्ट कोड संघनक विकल्प था जो पठनीयता का त्याग नहीं करता है।

जहाँ तक यह कोड को कैसे प्रभावित करता है? मैंने कभी भी किसी प्रदर्शन में वृद्धि या कमी पर ध्यान नहीं दिया है, मान लीजिए, कोड की 100 लाइनें। साधारण तथ्य यह है कि अंतिम उत्पाद पर पहुंचने के लिए आपके द्वारा उपयोग की जाने वाली लाइनों की संख्या की तुलना में यह अधिक प्रक्रिया है। मैंने कुछ प्रक्रियाओं को बहुत संघनित लिखा है, हालांकि, अक्षम, बेहतर कोड प्रवाह के साथ लंबे समय तक कोड से अलग प्रदर्शन करते हैं।

— जोशुआ वोलेरिक्स
स्रोत

आपका मतलब हैvalue.prop = boolean ? option1 : option2;

— क्रिस्टोफर हम्मर्स्ट्रम

मैं करता हूँ! ... वैसे भी 'संघनित कोड' पर।

— यहोशू वोलेरिक्स

2

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

— एंड्रेस एफ।

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

— jwenting

9

IMO, यह एक तुच्छ LOC गणना द्वारा कोड की प्रभावशीलता को मापने के लिए एक बुरा विचार है। ठीक से इंजीनियर और प्रभावी कोड बनाने के लिए बहुत कुछ है।

मेरे अनुभव में, प्रभावी कोड:

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

— डिनो ऑक्टेवियन
स्रोत

1

आइंस्टीन बोली के लिए +1।

— जस्ट्साल्ट

6

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

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

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

कम LOC काउंट्स के लिए स्पष्ट लाभ हैं (छोटे तरीके आपके सिर में बड़े लोगों की तुलना में अधिक आसानी से फिट होते हैं, कोड में कम चीजों का मतलब है कि गलत चीजें कम गलत हैं, आदि), लेकिन यह भी कम रिटर्न के कानून के अधीन है। 10 लाइन विधि को 7 लाइन विधि में बदलने की तुलना में 20 पंक्ति विधियों की संख्या में 150 लाइन विधि को फिर से लाना एक बहुत बड़ी जीत है।

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

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

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

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

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

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

— GordonM
स्रोत

2

मुझे लगता है कि आपको वास्तव में SLOC की एक छोटी संख्या के साथ कार्य करने का प्रयास करना चाहिए।

यदि LOC (कोड की लाइनें) एक छोटी संख्या है, तो यह कोड को कैसे प्रभावित करता है और यदि LOC एक बड़ी संख्या है, तो यह कोड को कैसे प्रभावित करता है?

आदर्श रूप में, एक नज़र में कोड की 8 पंक्तियों को समझना आसान होना चाहिए, जितना कि 30 को समझना चाहिए।

इसका मतलब यह नहीं है कि 8 लाइनों में संकुचित 30 LOC को समझना आसान होगा।

आपको क्या लगता है कि चीजों को करने का सही तरीका क्या है।

आम तौर पर एक समारोह में, मैं इसे अमूर्त के स्तरों ("IO कोड यहाँ", "यहाँ सत्यापन", "यहाँ गणना" इत्यादि) के आधार पर समूहित करने की कोशिश करता हूँ।

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

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

— utnapistim
स्रोत

2

मुझे लगता है कि LOC की तुलना में स्वच्छ, स्वतः-प्रलेखित कोड पर ध्यान देना अधिक महत्वपूर्ण है। मैं वास्तव में आपके उदाहरण को पसंद नहीं करता, हालांकि, यह बताता है कि कोड क्या कर रहा है, बिना यह कहे कि क्यों। उदाहरण के लिए, यह:

बूलियन स्वीट_सिक्स = (आयु == 16);

बहुत बेमानी है। कोई भी "उम्र == 16" पढ़ता है वह जानता है। मैं इस तरह कोड लिखूंगा:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

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

— एडुआर्डो स्कोज़
स्रोत

2

मधुर सोलह का महत्व (और 21 वर्ष की आयु) संस्कृति विशिष्ट है। "स्वीट सोलह" वाक्यांश "आयु == 16" से अधिक खोज योग्य है। के लिए है कि कारण कुछ बूलियन्स को नाम देने उपयोगी हो सकता है। मैं आपकी सामान्य भावना से सहमत हूं, हालांकि: आत्म-व्याख्यात्मक कोड की व्याख्या करने में समय बर्बाद न करें।

— जोनास कोल्कर

1

मुझे लगता है कि कोड की कम लाइनें = अधिक पठनीय कोड

लेकिन निश्चित रूप से, कुछ सीमाएं हैं, जब आप कम लाइनों को प्राप्त करने के लिए अपने कोड को छोटा / अस्पष्ट करना शुरू करते हैं।

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

यह न्यूनतम है तर्क वही रहता है, जो कम पठनीय है। यह मनुष्यों द्वारा नहीं किया जाना चाहिए, यह खनन मशीन द्वारा मशीन द्वारा पढ़ा जाना है।

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

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

— Vitim.us
स्रोत

1

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

— zhouji
स्रोत

1

मैं सामान्य परिस्थितियों में एक मुद्दे के रूप में लाइनों की संख्या नहीं देखूंगा, लेकिन यह मुद्दों की ओर इशारा कर सकता है। यदि कुछ-एक आपको 1000 लाइनों के कोड के साथ एक वर्ग दिखाता है, तो कुछ गलत होना चाहिए जिस तरह से वर्ग किया गया था या डिज़ाइन किया गया था।

आपका उदाहरण एक ऐसे मामले की ओर इशारा करता है जहां बड़ी संख्या में कोड की लाइनें समझ में आती हैं। लेकिन वह उदाहरण है। हर दिन मैं ऐसे उदाहरण देखता हूं जहां योजना की कमी से लाइनों की संख्या जुड़ी हुई है

— IvoC
स्रोत

0

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

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

— जेम्स जेन्सेन
स्रोत

0

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

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

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

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

— पॉल डे व्रीज़
स्रोत

-1

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

— johnfound
स्रोत

-1

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

— व्लादिमीर कोकजेन्सिक
स्रोत

-2

मैं मानता हूं कि हमेशा LOC में कमी की वजह से कोड को पढ़ना मुश्किल होगा।

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

— MatthieuW
स्रोत

5

जहां तक मुझे पता है, टिप्पणियां LOC की ओर नहीं आती हैं।

— मेहर

1

यह आपके द्वारा उपयोग की जाने वाली परिभाषा के अनुसार गिनती या इसे गिनता नहीं है।

— MatthieuW

1

टिप्पणियाँ टिप्पणियाँ हैं। वे कोड नहीं हैं। इसलिए वे LOC काउंट पर लागू नहीं होते हैं। जबकि स्व-दस्तावेजीकरण कोड अच्छी तरह से टिप्पणी किए गए कोड से बेहतर है, लेकिन कम स्पष्ट कोड से टिप्पणियों को हटाना किसी के लिए उपयोगी नहीं है।

— गॉर्डन

-2

केवल एक चीज है जो कोड उपायों की लाइनें है और वह आपके पास कोड की लाइनों की संख्या है। बाकी सब कुछ गर्म हवा, अटकलें और पूर्वाग्रह हैं।

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

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

संपादित करें

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

अब निम्नलिखित पर विचार करें:

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

तो - कोड की लाइनें एक टूटी हुई मीट्रिक है। कोड की कम लाइनें अतिरिक्त प्रदर्शन की गारंटी नहीं देती हैं - कि एपीआई या लाइब्रेरी कॉल एक लाइन है और आपके नियंत्रण से बाहर हो सकती है। कोड की कम लाइनें अतिरिक्त मजबूती की गारंटी नहीं देती हैं - त्रुटि की जाँच और सफाई को हमेशा अतिरिक्त लाइनों की आवश्यकता होगी। कोड की कम पंक्तियाँ अतिरिक्त पठनीयता या रखरखाव की गारंटी नहीं देती हैं - यह जानने के लिए आपको केवल IOCCC को देखना होगा ।

तो कोड की कम लाइनें क्या गारंटी देती हैं? कोड की कम लाइनें, बस इतना ही।

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

— रेव्ह mh01
स्रोत

1

परिभाषा के अनुसार , यदि किसी कार्य को पूर्ण करने के लिए कोड की एन लाइनों की आवश्यकता होती है (जो पहले स्थान पर निर्धारित करना कठिन है), तो यह एन लाइनों से कम में नहीं किया जा सकता है। तो आपका 10,000-लाइन का काम 2,000, अवधि में नहीं किया जा सकता है। मुझे लगता है कि ओपी उन मामलों के बारे में बात कर रहा है, जहां कुछ रास्ते हैं, "आवश्यकता को पूरी तरह से पूरा किया जा सकता है, इसलिए कौन सा बेहतर है?"

— एंड्रेस एफ।

-3

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

— Infin8Loop
स्रोत

1

सभी डाउनवोट क्यों?

— मार्को

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

— मैक्सिमस मिनिमस

1

@ mh01 मैं अनुमान लगा रहा हूं क्योंकि इसमें से अधिकांश गलत है? विशेष रूप से,

in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable steps

मेरा अनुभव बिल्कुल नहीं है। जटिल कोड को अक्सर छोटे और सरल बनाकर अधिक पठनीय और कम बगिया बनाया जा सकता है, क्योंकि यह किसी ऐसे व्यक्ति द्वारा लिखे जाने से जटिल हो गया जो भाषा के लिए नया था / समस्या के लिए नया था / निश्चित नहीं कि वे क्या कर रहे थे।

— इज़्काता

-5

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

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

— विभु तिवारी
स्रोत

5

-1: वाह! मुझे लगता है कि आपको अपने उत्तर में LOC कम करने की आवश्यकता है! इसे पढ़ने के लिए मेरी आँखें दुखती हैं!

— जिम जी।

1

@ जिम: मैं मानता हूं कि उत्तर मेरी आंखों को नुकसान पहुंचाता है, लेकिन लगता है कि यह एलओसी (प्रत्येक गिने आइटम के लिए एक अलग लाइन का उपयोग करके) बढ़ाकर सबसे अच्छा हल है।

— ब्रायन

ऑटोफ़ॉर्मैटर की गलती थी, सूची से पहले एक खाली लाइन डालने से सीटूशन ठीक हो गया

— पाल