वर्णनात्मक नामकरण बनाम 80 वर्ण रेखाएं [बंद]

Question

मैं अक्सर इन दो मूल्यवान प्रोग्रामिंग प्रथाओं को सुनता हूं: (1) कोड की लाइनें 80 वर्ण या उससे कम होनी चाहिए और (2) चर, विधियों, कक्षाओं आदि के लिए वर्णनात्मक नामों का उपयोग करें, मैं सलाह के इन दोनों शब्दों के तर्क को समझता हूं, हालांकि , वे अक्सर एक दूसरे के ट्रेडऑफ़ लगते हैं। अगर मैं अपना कोड 80 वर्ण / रेखा से नीचे रखता हूं, तो मैं कम वर्णनात्मक नाम (esp। पायथन में, जिसमें प्रत्येक इंडेंटेशन 4 वर्णों के रूप में गिना जाता है) का उपयोग करके समाप्त होता है, लेकिन यदि मैं अधिक वर्णनात्मक नामों का उपयोग करता हूं, तो मैं 80 वर्णों की रेखाओं के साथ समाप्त होता हूं।

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

Comments

@BillyONeal बड़ी स्क्रीन के साथ, 120 :)

— BЈовић

मुझे लगता है कि मुझे

— 9

मैं can० को पसंद करता हूं, क्योंकि मैं अपनी नोटबुक पर साइड से २ फाइलें आसानी से खोल सकता हूं।

— होन्ज़ा ब्रेबेक

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

— पीयर स्ट्रिट्जिंगर

@ ott--: क्या आपने एक संपादक को देखा है, जो वास्तव में C ++ सिंटैक्स के अनुसार एक लंबी लाइन को तोड़ सकता है, और निरंतरता को शुरुआत से एक और स्तर पर प्रस्तुत कर सकता है? अन्यथा ऐसा सुझाव बेकार है।

— जन हुदेक जनवरी १13

Answer 1

अपने इंडेंट कुछ, अपने नाम वर्णनात्मक रखें, और एक लाइन को तोड़ने से डरो मत।

अपने संकेत कुछ कम रखें।

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

आपके नाम वर्णनात्मक हैं

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

एक लाइन तोड़ने से डरो मत

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

Comments

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

— जन हुदेक

Answer 2

क्यों न दोनों?

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

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

मूल रूप से 1970 के पाठ टर्मिनलों की तकनीकी सीमाओं के परिणामस्वरूप 80-वर्ण की सीमा, आज भी कई लोगों द्वारा मूल्यवान है, और भले ही अभी भी तकनीकी कारण हैं (कुछ नेटवर्क प्रोटोकॉल में अधिकतम लाइन लंबाई, सबसे विशेष रूप से ई-मेल से संबंधित), अधिक सम्मोहक कारण मनोवैज्ञानिक और सामाजिक हैं। यह पता चलता है कि प्राकृतिक-भाषा गद्य के लिए सबसे आरामदायक पढ़ने के अनुभव के लिए 66 वर्ण चिह्न के चारों ओर लाइन की लंबाई (फ़ॉन्ट आकार दिलचस्प रूप से बहुत अंतर नहीं करता है, और नतीजतन, न तो स्क्रीन या पेपर का आकार होता है); 80-वर्ण रेखा की सीमाएं उसके बहुत करीब हैं, लेकिन चूंकि कोड के एक विशिष्ट टुकड़े का थोक आमतौर पर कम से कम एक या दो स्तरों (जो 4 और 16 वर्णों के बीच का अर्थ होता है, इंडेंटेशन सेटिंग्स के आधार पर) के लिए प्रेरित होता है,

80-वर्ण वाली रेखाओं से चिपके रहने का एक और प्रभाव यह है कि जब चीजें बहुत जटिल होती हैं तो यह बहुत अच्छा संकेतक होता है। आम तौर पर निम्न में से एक के कारण होने वाली लाइनें:

• तर्कों की लंबी सूची के साथ कार्य; यह एक अच्छी बात नहीं है, क्योंकि वे पठनीयता को बाधित करते हैं और आसानी से सूक्ष्म कीड़े पैदा कर सकते हैं, उदाहरण के लिए जब लोग तर्क क्रम को स्वैप करते हैं ताकि कंपाइलर पकड़ न सके।
• जटिल अभिव्यक्ति, अक्सर सशर्त में पाए जाते हैं (जैसे if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); यह भी, आमतौर पर समझने के लिए कठिन है, और कोड को कुछ और संरचित में फिर से लिखना चाहिए। सबसे अधिक संभावना है, अभिव्यक्ति बहुत अधिक है और इसे एक विधि या फ़ंक्शन में विभाजित किया जाना चाहिए।
• फंक्शन कॉल या एक्सप्रेशन में इस्तेमाल होने वाले लंबे शाब्दिक, जैसे print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));। शाब्दिक को एक चर या स्थिर में स्थानांतरित करें; यह अभी भी लाइन की लंबाई को पार कर सकता है, लेकिन यदि आप इसे लगातार करते हैं, तो पाठक लाइन के अदृश्य भाग को कम से कम सुरक्षित रूप से अनदेखा कर सकता है, यह मानते हुए कि केवल शाब्दिक शेष है। या बेहतर अभी तक, शाब्दिक कोड से बाहर और एक बाहरी डेटा स्टोर (फ़ाइल, डेटाबेस, जो भी हो) में स्थानांतरित करें।
• ifएक कक्षा विधि में बयानों के छह स्तरों (जैसे कि विशिष्ट सेटिंग्स के लिए इंडेंटेशन के 32 कॉलम) को गहराई से नेस्टेड स्टेटस । फिर से, गहरे घोंसले के शिकार जटिल और कठिन पढ़ने के लिए कोड बनाता है, और प्लेग की तरह बचा जाना चाहिए - बस, गहरी घोंसले के शिकार पढ़ने के दौरान मानव मस्तिष्क के ढेर को ओवरफ्लो करता है।

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

Comments

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

— जन हडेक

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

— जन हुदेक जन १13

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

— तदमर्स

Answer 3

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

Comments

इस। X वर्णों पर लाइनें तोड़ना बंद करें, IDE को संभालें। इसके अलावा, आप अन्य सभी उपयोगकर्ताओं (भविष्य के आप सहित!) को परेशान करते हैं जो स्क्रीन / आईडीई के कोड के साथ 2 * X वर्णों को संभाल सकते हैं जो अब एक पृष्ठ पर फिट नहीं होते हैं।

— कोनरक

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

— कोनराड रूडोल्फ

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

— जन हुदेक जनवरी १13

Answer 4

प्रति पंक्ति 80 वर्ण नामकरण को पूरा करने के लिए भी मुश्किल नहीं है क्योंकि लंबे समय से कोड की एक पंक्ति को कई छोटे कोड में तोड़ने के कई तरीके हैं, उदाहरण के लिए, मैं 40 से कम में फिट होने के लिए सी में एक शर्त बयान को कई लाइनों में तोड़ सकता हूं पात्र,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

आप कई लाइनों में कॉल फ़ंक्शन की एक पंक्ति को भी विभाजित कर सकते हैं।

इसलिए, वर्णनात्मक नामकरण और 80 वर्ण रेखाओं के दोनों नियमों में कोई विरोधाभास नहीं है, वे पठनीयता में सुधार करने के लिए सह-अस्तित्व में आ सकते हैं।

Comments

क्या 80 अक्षर वास्तव में पठनीयता में सुधार करते हैं? क्या स्क्रीन आसानी से इन दिनों 120 नहीं कर सकती है?

— बिली ओनेल

@ बिलियोनियल के लिए 120 से अधिक चौड़ाई की तुलना में 80 से अधिक चौड़ाई को स्कैन करना आसान है

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

समाचार पत्र स्तंभों में टूट जाते हैं, और आपके पास ux ux.stackexchange.com/questions/3618/…

— neo

तर्क की स्थिति को तोड़ने से पठनीयता में सुधार होता है जब लाइन टूटती है स्थिति संरचना से मेल खाती है, लेकिन जरूरी नहीं कि अगर वे केवल कुछ मनमानी सीमा के अनुरूप हों।

— मिकोलाक

@ बिलियन: अधिकांश स्क्रीन 120 कर सकते हैं, लेकिन शायद ही कोई 240 कर सकता है। या क्या आप कभी भी अंतर की तुलना नहीं करते हैं?

— ह्यूबर्ट करियो

Answer 5

80 सीमा एक ऐसी चीज है जिसे बहुत पहले बढ़ा दिया जाना चाहिए था। ध्यान दें कि यह सीमा उम्र के बाद से प्रयोग की जाती है जब प्रत्येक पहचानकर्ता की लंबाई 8 वर्णों तक सीमित थी और स्क्रीन / प्रिंटर पर केवल एक ही फ़ॉन्ट था। फ़ॉन्ट आकार बदलने की कोई संभावना नहीं है।

भगवान, हमारे पास अब अलग स्क्रीन और प्रिंटिंग तकनीक है। हमारे पास बहुत अलग प्रोग्रामिंग भाषाएं हैं। अब 80 अक्षरों का उपयोग करने का कोई कारण नहीं है। इसे बढ़ाकर कम से कम १२० चार्ट करें।

फिर भी यह एक कठिन सीमा नहीं होनी चाहिए। आप लाइन पर एक चरित्र जाओ? खैर, कुछ नहीं होता है!

संपादित करें:

80-चार सीमा के इतिहास के बारे में विस्तृत उत्तर

विकिपीडिया पर प्रति पंक्ति वर्ण

विचिटा स्टेट यूनिवर्सिटी के एक अध्ययन में पाया गया कि सीपीएल में पठनीयता पर केवल छोटे प्रभाव थे, जिसमें गति और समझ के कारक शामिल थे। प्राथमिकताओं के लिए पूछे जाने पर, हालांकि, 60% उत्तरदाताओं ने अध्ययन में प्रयुक्त सबसे छोटी (35 सीपीएल) या सबसे लंबी (95 सीपीएल) लाइनों के लिए वरीयता का संकेत दिया। इसी समय, 100% उत्तरदाताओं ने इनमें से किसी एक मात्रा को कम से कम वांछनीय के रूप में चुना।

Comments

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

— जान हुदेक जनवरी १13

@ जानहुडेक इसमें स्क्रीन / प्रिंटिंग तकनीक के साथ सब कुछ है। प्रोग्रामर्स का संदर्भ लें ।stackexchange.com/questions/ 148677/… । 80 वर्णों के साथ जाने का निर्णय विशुद्ध रूप से ऐतिहासिक है, अध्ययन पर आधारित नहीं है। क्या आप अपनी राय की पुष्टि करने के लिए अध्ययन के लिंक जोड़ सकते हैं?

— सुल्तान

एक और सवाल यह टिप्पणी में पहले से ही UX लिंक मिला है ; आगे के संदर्भ। जबकि संख्या rough० अपने आप में ऐतिहासिक संयोग है, यह टाइपराइटरों पर प्रति पंक्ति की संख्या से मोटे तौर पर व्युत्पन्न है, जो कि सिंगल-कॉलम प्रिंट की सामान्य चौड़ाई से मोटे तौर पर व्युत्पन्न था और औसतन ६६ अक्षरों की लंबाई इसके लिए लंबे समय से स्थापित परंपरा थी।

— Jan Hudec