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


56

एक वाइडस्क्रीन मॉनिटर पर एक बार में स्क्रॉलबार के बिना 80 से अधिक अक्षर आसानी से देखे जा सकते हैं। यहां तक कि लिनुस टोर्वाल्ड के रूप में 80 वर्ण की सीमा देखता है पुराना

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


1
जैसे कि ग्रहण में रेखाओं को छोटा रखने का एक बहुत अच्छा कारण है। यह आपको बिना लाइन रैपिंग के एक पठनीय फ़ॉन्ट में एक सामान्य प्रिंटर पर अपने प्रोग्राम को प्रिंट करने की अनुमति देता है ।

किस संदर्भ में? यदि आप एक विशिष्ट प्रोग्रामिंग संदर्भ में पूछ रहे हैं, तो मैं फिर से खोलने के लिए मतदान करूंगा।
निकोल


विजुअल स्टूडियो का वर्ड रैप टूट गया है, इसलिए अधिकांश उपयोगकर्ता इसे बंद कर चुके हैं। इसके बजाय, वे हाथ से लाइन ब्रेक लगाते हैं। यह एक अलग स्क्रीन चौड़ाई के साथ किसी के लिए भयानक लग रहा है। visualstudio.uservoice.com/forums/121579-visual-studio/…
कर्नल पैनिक

जवाबों:


28

80 वर्ण सीमा का पालन करने के कई कारण हैं (या, एक 74 वर्ण सीमा और भी बेहतर है; यह कोड के लिए 80 से कम स्तंभों को बनाए रखने की अनुमति देता है, जबकि अलग-अलग मार्कर और ईमेल उद्धरण जोड़े जाते हैं, अगर आप कोड समीक्षा करते हैं। ईमेल की सूची)।

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

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

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

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

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


3
माना। हालांकि, लंबे पहचानकर्ताओं को कभी-कभी प्रोत्साहित किया जाता है ("सार्थक नामों का उपयोग करें" या "गुप्त std::vector<...>::const_iteratorसंकेतों से बचें" जैसे दिशानिर्देशों को कोड करके) या आवश्यक (जैसे कि ), हालांकि बाद के मामले में, आमतौर पर चीजों को टाइपफेड द्वारा कम किया जा सकता है।
मुसीफिल

महान कारण। मुझे यकीन नहीं है कि सटीक लाइन लंबाई मायने रखती है, जब तक कि आपकी टीम (या मेलिंग सूची?) इससे सहमत है। व्यक्तिगत रूप से, मैं अंकल बॉब के सुझाव के साथ जाता हूं, जो 120 वर्णों से अधिक नहीं है।
एलन

1
@musiphil हाँ, इसीलिए मैंने अंतिम पैराग्राफ को शामिल किया। मैंने C ++ में लाइनों में भाग लिया है, जहां मैं विधि की घोषणा करते समय क्लास नाम, विधि नाम और एक 80 कॉलम लाइन पर वापसी प्रकार फिट नहीं कर सका। कुछ वास्तव में अजीब लाइन-ब्रेकिंग करने के बजाय, उस एक लाइन के लिए केवल 80 कॉलम (या 100 कॉलम) नियम को तोड़ना बेहतर है।
ब्रायन कैंपबेल

46

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

० अक्षर पुराने हो सकते हैं, लेकिन चीजों को यथावत रखने में कुछ योग्यता है।


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

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

1
80 वर्ण अभी भी उचित हैं; इससे अधिक लंबे समय तक रहने से नेस्टेड कोड को प्रोत्साहित करने (बदले के बजाय!) और कई खिड़कियों को एक साथ रखने के लिए असाधारण उपयोगी है। एक और मॉनिटर जोड़ने से सिर्फ एक बार आप देख सकते हैं कि खिड़कियों की संख्या बढ़ जाती है!
डोनल फैलो

1
80 शायद वीएमएस के अनुकूल है। मेरी नई उम्र की सोच को क्षमा करें, लेकिन हमें उस सीमा का विस्तार करना चाहिए जहां संभव हो और जहां आवश्यक हो ..
रॉस

29

मुझे नहीं लगता कि मॉनिटर का इससे कोई लेना देना है - कम से कम अब और नहीं।

यदि आप 80 वर्णों में एक पंक्ति को कोड नहीं कर सकते हैं, तो संभवतः वैसे भी बुरे कोड का संकेत है। बहुत जटिल भाव। बहुत गहरा आक्रोश। आदि। आपको रोकना चाहिए और जो आप कर रहे हैं उसे पुनर्विचार करना चाहिए।

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

मुझे व्यक्तिगत रूप से इस तरह के सामान से नफरत है:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

इसके बजाय बस:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
निश्चित रूप से यदि पहले उदाहरण में लाइन 3 बहुत लंबी नहीं है, तो लाइन 2 को लाइन 1 में जोड़ा जा सकता है, जिससे यह अधिक पठनीय लगता है। (क्या भाषा को कोष्ठकों के भीतर बची नई कहानियों की आवश्यकता है?)

1
आह, यह सिर्फ कुछ छद्म कोड मैंने लिखा है। लेकिन मुझे लगता है कि C को इसकी आवश्यकता है।
सीजर कैनसा

4
केवल बहु-पंक्ति स्थूल परिभाषाओं में, जो दुर्लभ हैं (या होनी चाहिए)। यह अधिकतम लाइन लंबाई की पसंद को प्रभावित करता है (ऐसे बैकस्लैश को बनाए रखना मज़ेदार नहीं है), इसलिए मैं उत्सुक हूं कि आप इसे क्यों दिखाते हैं। एक तिनके का आदमी लगता है ?

2
यदि मैं एक फ़ंक्शन कॉल में एक पंक्ति को तोड़ने की समस्या के लिए जाता हूं, तो मैं प्रत्येक पैरामीटर को अपनी लाइन पर रखूंगा, एक स्तर से प्रेरित।
स्टारबेल

20

कोडिंग के लिए?

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


3
जबकि मुझे लगता है कि कोड गद्य से बहुत अलग है, यह कोड को पढ़ने के लिए थकाऊ है कि समय-समय पर (यानी गद्य आमतौर पर बहुत अधिक सुसंगत होगा) 120+ स्तंभों तक लाइनों को फैलाता है।

6

हां, कोड लाइन की लंबाई सीमित करने के कारण हैं:

  1. हालांकि हमारी स्क्रीन व्यापक हो गई है, कभी-कभी आपको अपना कोड प्रिंट करना होगा। यदि केवल इस कारण से
  2. डिफ-व्यूअर अक्सर एक ऊर्ध्वाधर विभाजन के साथ लाइनों को प्रदर्शित करते हैं - यह कठिन हो जाता है अगर लाइनें एक विस्तृत स्क्रीन की अनुमति होती हैं।

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

मैं कहूंगा कि अतिरिक्त लंबी लाइनों को अस्वीकृत नहीं किया जाना चाहिए, क्योंकि कभी-कभी वे आवश्यक होते हैं । लेकिन अगर अधिकांश फ़ंक्शन केवल 30 "स्क्रीन पर देखने योग्य हैं, तो कोड में कुछ समस्याएं हैं।


5

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


3

संभवतः 80 अक्षर की सीमा का चयन करना प्रासंगिक नहीं है; उदाहरण के लिए, सीमा 85 होने पर क्या बदल जाएगा?

यह सच है कि आजकल उपयोग किए जाने वाले मॉनिटर में उच्च रिज़ॉल्यूशन होते हैं, लेकिन एक टेक्स्ट एडिटर / आईडीई में, टेक्स्ट दृश्य से सभी स्थान नहीं लिया जाता है; संपादक में मैं प्रोजेक्ट में शामिल फ़ाइलों की सूची को बाईं ओर दिखाता हूं।

किसी नेटबुक या नोटबुक में उपयोग किया जाने वाला रिज़ॉल्यूशन मॉनिटर में उपयोग नहीं किया जाता है; यह शायद एक चरित्र सीमा का उपयोग करने के लिए समझ में आता है जो किसी को भी "समस्याएं" पैदा नहीं करता है।


5
80 अक्षर पंच कार्ड पर कॉलम की संख्या की कठिन सीमा थी!
ChrisF

5
इससे कोई फर्क नहीं पड़ता कि मानक क्या है, लेकिन अगर हर कोई एक ही मानक पर काम करता है तो इससे जीवन आसान हो जाता है।
8 अक्टूबर को Skilldrick

2

यह वास्तव में विकास के माहौल पर निर्भर करता है।

उदाहरण के लिए, हजारों डेवलपर्स वाले एक बड़े निगम में, संभवतः ऐसे सैकड़ों लोग हैं जो किसी उत्पाद के जीवनकाल के दौरान, इसके कोड के कुछ हिस्से को देखना होगा। बहुत से लोगों के साथ, कुछ ऐसे लोग हैं, जो किसी भी कारण से (पुराने हार्डवेयर, नेटबुक आदि) 800x600 या उससे छोटे पर काम कर रहे हैं। उन्हें समायोजित करने के लिए कुछ मूल्य है।

मेरी 25-व्यक्ति कंपनी में, हालांकि, मैं कहता हूं कि यह पेंच है। हम सभी अधिकतम रिज़ॉल्यूशन- 120-140 पर दोहरी आधुनिक मॉनिटर का उपयोग कर रहे हैं या अनौपचारिक दिशानिर्देश है।


2

कुछ सीमा निश्चित रूप से समझ में आता है। लेकिन 80 वर्णों की सीमा बहुत अधिक विवश है। मैं 96 चरित्र की सीमा जैसा कुछ पसंद करता हूं। यह उन सभी कोडों के लिए पर्याप्त रूप से विस्तृत है जिनसे मुझे निपटना है और यह पर्याप्त संकीर्ण हैं ताकि दो फाइलों को diff'ing (चौड़ी स्क्रीन पर) के लिए एक साथ रखा जा सके।

मेरा मानना ​​है कि कोड पठनीयता अन्य सभी चिंताओं को रौंद देती है। और प्रति वर्ण के साथ 96 वर्णों को 80 के साथ अधिक पठनीय बनाया जा सकता है।

मैं इस तर्क को नहीं खरीदता कि ज्यादातर लोग अपने टर्मिनलों को 80 वर्णों तक सेट करते हैं, न कि प्रिंटर को 80 वर्णों से लंबी लाइनों को लपेटना पड़ता है। यह एक कठिन सीमा नहीं है क्योंकि यह अतीत (दूर) में हुआ करता था। आप टर्मिनल और प्रिंटर की चौड़ाई 100 वर्णों तक आसानी से सेट कर सकते हैं।


1

नहीं, यह अब प्रासंगिक नहीं है:

  • वेब और अनुप्रयोगों में उपयोग किए जाने वाले अधिकांश फोंट वैसे भी निश्चित-चौड़ाई वाले नहीं होते हैं। दूसरे शब्दों में, 80 वर्ण! = 80 वर्ण।
  • जैसा कि आपने कहा, स्क्रीन की चौड़ाई बदल गई है - 80 अक्षर एक समझदार सीमा नहीं है।

80 वर्ण वास्तव में कंसोल वातावरण में निश्चित-चौड़ाई वाले फोंट के लिए एक दिशानिर्देश थे।

बेशक, यदि आप अभी भी कंसोल वातावरण में एक निश्चित-चौड़ाई वाले फ़ॉन्ट का उपयोग कर रहे हैं ... तो निश्चित रूप से, 80 वर्ण समझदार हैं :)


3
मुझे पूरा यकीन है कि वह स्रोत कोड में 80-वर्ण की सीमा के उपयोग की बात कर रहा था, जो लगभग सार्वभौमिक रूप से मोनोस्पेस वाले फोंट में प्रदर्शित होता है।
1

1
हम्म ... उस मामले में ... अभी भी नहीं, लेकिन अन्य कारणों से :)
दामोविसा

1
80 अक्षर पंच कार्ड पर कॉलम की संख्या की कठिन सीमा थी!
ChrisF

0

यदि आप एक GUI में संपादक का उपयोग करते हैं, तो प्रति पंक्ति 80 अक्षर अप्रासंगिक हैं, क्योंकि अधिकांश सभ्य संपादकों - उदाहरण के लिए नोटपैड ++ - लाइन रैप को टॉगल करने के लिए एक बटन है। उस के साथ, यह एक समस्या नहीं होनी चाहिए, यहां तक ​​कि एक पतली खिड़की में कोड को देखने पर भी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.