सोर्स कोड लिखते समय 80 कैरेक्टर लिमिट बेस्ट प्रैक्टिस का पालन कैसे करें?

15

तो जैसा कि आप जानते हैं कि एक सर्वोत्तम प्रथा है

80 वर्णों में स्रोत कोड की एक पंक्ति को सीमित करें।

यहाँ 2 लिंक दिए गए हैं:

कोड की चौड़ाई के लिए 80 अक्षर 'मानक' की सीमा क्यों है?

क्या वाइडस्क्रीन मॉनिटर के समय में 80 वर्ण की सीमा अभी भी प्रासंगिक है?

और मुझे यकीन है कि यदि आप इस सर्वोत्तम अभ्यास की खोज करते हैं तो आप अधिक ठीक कर सकते हैं।

लेकिन मुझे यह बहुत मुश्किल लगता है, यहाँ एक नमूना उदाहरण है:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

तो आप प्रत्येक वर्ग और प्रत्येक विधि और प्रत्येक कथन पर ध्यान दें।

और मैं 'myReference' में पिछले 'e' के अंत तक पहले से ही कॉलम 60 पर हूं।

मेरे पास 20 रिक्त स्थान हैं जो वास्तव में कंस्ट्रक्टर को कॉल करते हैं और मेरे पास मौजूद संदर्भ के लिए ऑब्जेक्ट असाइन करते हैं।

मेरा मतलब है कि यह वास्तव में बेहतर दिखता है:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>();

यहां सबसे अच्छा अभ्यास क्या है?

coding-style

— कोरे तुगे
स्रोत

6

हम इसे 140 बनाते हैं। 80 छोटे परदे और छोटे प्रिंटर के दिनों में अच्छा रहा होगा

— tgkprog

7

सबसे अच्छा अभ्यास जब तक आप अंत के जीवन संस्करणों पर हैं की तरह 5/6 संभावना होगी final Map<String, List<MyInterfaceHere>> myReference = new HashMap<>();(जैसे खरोज के साथ 80 वर्ण अपने उदाहरण में)

— मच्छर

4

एक मेटा-बेस्ट-प्रैक्टिस बीस साल पहले से नेत्रहीन रूप से सर्वोत्तम प्रथाओं का उपयोग नहीं करना है। जब एक 17 "CRT ने 1280x1024 रिज़ॉल्यूशन का स्पोर्ट किया, तो कम वर्ण सीमाएं समझ में

— आईं

2

ध्यान दें कि आपके प्रदर्शन में सभी उपलब्ध स्थान में फैलाव के बजाय पाठ के संकीर्ण स्तंभों का उपयोग करने का एक फायदा, कोड साइड के कई टुकड़ों को आसानी से देखने की क्षमता है। 80 chars * 7 pixels/char = 560 pixels per file। यह दो फ़ाइलों (1120 px) को 1280 px चौड़ी स्क्रीन पर आराम से फिट करने की अनुमति देता है, या 1920 px स्क्रीन पर तीन (1680 px), दोनों ही मामलों में लाइन नंबर, स्क्रॉल बार, सिगिल और अन्य UI तत्वों के लिए कुछ अतिरिक्त स्थान छोड़ता है। । या यहां तक कि सामयिक थोड़ा लंबी रेखा।

— 8bittree

3

@ 8bittree मैं दो साइड पर कोड साइड देख सकता हूं। सिंगल मॉनीटर पर विकसित करना केवल एक पहिया के साथ कार चलाने जैसा है।

18

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

/* Very long comment to the end of the line */ realCode ();

जहां फ़ंक्शन कॉल स्क्रीन पर दिखाई नहीं दे रहा था (न ही यह किसी सहकर्मी की स्क्रीन पर दिखाई दे रहा था) बिना किसी संकेत के।

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

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

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

— gnasher729
स्रोत

10

लगता है जैसे /* Very long comment to the end of the line */ realCode ();पहले से ही कुछ अन्य शैली के नियमों को तोड़ना चाहिए।

— रॉबर्ट हार्वे

3

/* Very long comment to the end of the line */ realCode ();आईडीई के पास कोड स्वरूपक होने का एक कारण है जो टिप्पणी और कोड को स्वचालित रूप से अलग-अलग लाइनों पर रखता है।

2

यह उसी स्रोत से आया है जिसने बदनाम रूप से लिखा है "अगर (स्थिति) \ n \ tgoto से बाहर निकलें, \ n \ ngoto से बाहर निकलें;"। अभी कुछ साल पहले।

— gnasher729

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

— अल्फा_989

3

हाँ, यह बेहतर दिखता है। यही कारण है कि "लंबी लाइनों का उपयोग न करें!" मैक्सिम इतना मजबूत है।

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

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

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

— किलियन फोथ
स्रोत

1

लक्ष्य "80 वर्णों की रेखाएं नहीं रखना" है। लक्ष्य है "अपने कोड को पढ़ना और समझना आसान बनाएं"। आर्टिफिशियल 80 कैरेक्टर लिमिट रीडबिलिटी में मदद करता है, लेकिन जब तक आपकी टीम यह तय नहीं करती है, यह एक कठिन और तेज़ नियम नहीं है।

आपने सबसे अच्छा अभ्यास करने के लिए कहा, और सबसे अच्छा अभ्यास "कोड को यथासंभव पठनीय बनाने पर ध्यान केंद्रित करना" है। यदि इसके लिए 80 से अधिक पात्रों की आवश्यकता है, तो ऐसा ही होना चाहिए।

— ब्रायन ओकली
स्रोत

1

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

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

सही किया, बड़े करीने से टूटी हुई रेखा एक बहुत अधिक पठनीय है जो स्क्रीन के किनारे से गायब हो जाती है।

— साइमन बी
स्रोत

1

यदि आप कोड की लंबाई / चौड़ाई को लागू करते हैं, तो एक उपकरण का उपयोग करें।

Resharper
विजुअल असिस्ट
आदि।

डेवलपर्स तय करते हैं कि एक उचित लंबाई क्या है (80, 120, 200, आदि), उस विकल्प को उपकरण में सेट करें।

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

माइंडलेस और आसान और हर सोर्स फाइल को उसी तरह फॉर्मेट किया जाएगा।

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

0

इन दिनों 80 char की सीमा थोड़ी कम हो सकती है, लेकिन यह मदद करता है। मैं उन सभी मतों से सहमत होना चाहता हूं कि कोड को अच्छी तरह से स्वरूपित किया जाना चाहिए। जैसे कोड

/ * पंक्ति के अंत में बहुत लंबी टिप्पणी * / realCode ();

80 chr के भीतर हो सकता है लेकिन टिप्पणी के रूप में भ्रम पैदा करता है और कोड विकल्प एक ही लाइन पर हैं।

80 chr सीमा का पालन करना या न करना व्यक्तियों की पसंद है लेकिन अगर चीजें एकल शॉट में दिखाई देती हैं तो यह हमेशा प्रोग्रामर और अन्य समीक्षकों को भी एक आरामदायक दृष्टिकोण और एहसास देगा।

— user220681
स्रोत