मैं कोड में सादगी को कैसे परिभाषित और माप सकता हूं?

Question

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

मैं कोड में सादगी को कैसे परिभाषित कर सकता हूं? कोड सादगी को मापने के लिए कौन से सॉफ्टवेयर माप और मीट्रिक उपलब्ध हैं?

Comments

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

— थॉमस ओवेन्स

@ThomasOwens असली सवालों के जवाब हैं , विचार या राय नहीं। स्कोप को कम करना इसलिए हर कोई इस तरह से सवाल का जवाब देने की व्याख्या करता है कि वास्तव में स्टैक एक्सचेंज क्या है। समस्या को हल करने के लिए एक से अधिक दृष्टिकोण हो सकते हैं, लेकिन केवल एक स्पष्ट रूप से बताई गई समस्या है।

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

— थॉमस ओवेन्स

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

— थॉमस ओवेन्स

Answer 1

जटिलता को मापने के लिए सबसे आम मैट्रिक्स (या सादगी, यदि आप जटिलता के विपरीत होने के लिए सरलता लेते हैं) मैककेबे के साइक्लोमैटिक कॉम्प्लेक्सिटी और हाल्टड कॉम्प्लेक्सिटी मेट्रिक्स हैं ।

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

Halstead जटिलता उपाय कुल और अलग-अलग ऑपरेटरों और ऑपरेंड्स के इनपुट का उपयोग करके कोड के एक टुकड़े की मात्रा, कठिनाई और प्रयास की गणना करते हैं। कठिनाई, जो (अद्वितीय ऑपरेटरों / 2 की संख्या) * (ऑपरेंड की कुल संख्या / अद्वितीय ऑपरेंड की संख्या) है, सिस्टम को सीखने या कोड समीक्षा करने जैसे कार्यों के लिए कोड को पढ़ने और समझने की क्षमता से बंधा है। फिर, आप इसे सिस्टम स्तर, एक कक्षा स्तर, या एक विधि / फ़ंक्शन स्तर पर गिन सकते हैं। इन मापों की गणना करने के बारे में कुछ पोस्टिंग यहां और यहां दी गई है ।

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

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

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

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

Comments

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

— रायथल

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

— जेम्स एंडरसन

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

— थॉमस ओवेन्स

Answer 2

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

मैं सरलता के कुछ उपाय नहीं कर रहा हूं, लेकिन आप कुछ सरल करते हैं या नहीं।

1. कोड ट्रावरल: कोड के
माध्यम से नेविगेट करना कितना आसान है? क्या यह आसान है जहां एपीआई फ़ंक्शन लिखे गए हैं? क्या कॉल प्रवाह को समझना आसान है, उदाहरण के लिए कौन से तरीके दूसरों को बुला रहे हैं (और क्यों) - क्या अच्छी राज्य मशीनों को लागू किया गया है या सफाई से पहचाने गए एल्गोरिदम हैं?

जब कोड ट्रैवर्सल आसान होता है, तो कोड का पालन ​​करना सरल होता है।

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

3. व्याख्या और संदर्भ
क्या आपकी प्रत्येक विधि की स्पष्ट भूमिका है। क्या प्रत्येक चर / विशेषताएँ उस भूमिका को निर्धारित करना आसान है जो वे निभा रहे हैं? जब कोड का एक टुकड़ा कुछ ऐसा होता है, जो मान्यताओं को दर्शाता है या चर के असंबंधित सेट को प्रभावित करता है, तो एक रखरखाव दुःस्वप्न बन सकता है।

4. निर्भरता या युग्मन
यह सिर्फ कोड को देखकर न्याय करना मुश्किल है, लेकिन अगर कोई आपके कीड़े को ठीक करने की कोशिश करता है तो यह बहुत स्पष्ट हो जाता है। जब कुछ अन्य चीजें किसी अन्य वस्तु में बदलती हैं, तो क्या यहां ऑपरेशन बदलता है? क्या वे बदलाव स्पष्ट हैं? क्या आपको सामान को समायोजित करने के लिए एपीआई को अक्सर बदलने की आवश्यकता होती है। ये सुझाव देते हैं कि पारस्परिक संबंध सरल नहीं हैं

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

एक सामान्य प्रश्न जो मैं आमतौर पर पूछूंगा वह इस प्रकार है: यदि एक कार्यक्रम के बजाय, यदि मैं एक ही कार्य को एक मानव द्वारा करने के लिए कहूं, तो क्या मैंने इस जानकारी को एक कागज़ के रूप में भरा होगा ? यदि नहीं, तो मैं यहाँ सरल नहीं हूँ ।

मैं यह नहीं कहूंगा कि यह सूची संपूर्ण है, लेकिन मुझे लगता है कि मानदंड कितना आसान या कठिन है, इसका उपयोग करना और सॉफ्टवेयर को संशोधित करना है। यह सरल है।

Comments

उन्होंने माप और मैट्रिक्स के लिए कहा। ये व्यक्तिपरक होते हैं, इसलिए मुझे नहीं लगता कि ये बहुत महत्वपूर्ण हैं।

— psr

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

— दीपन मेहता

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

— पेर्ट टॉर्क

@ PéterTörök मैं सहमत हूं। मैं आमतौर पर लगता है, कई संगठनों, नामकरण रिवाजों का का बहुत स्पष्ट रूप से परिभाषित नियमों और अभी भी के बारे में कुछ भ्रम की स्थिति में उत्कटता विशेष चर बनी रहती है की। इसलिए यह कहना था कि औपचारिक नियम के विपरीत सादगी के लिए उद्देश्य मात्रा की स्पष्टता । हो सकता है कि मैं कैसे वर्णन में ओवरबोर्ड चला गया धन्यवाद।

— दीपन मेहता

@ डिपान साइक्लोमैटिक जटिलता कार्य मेमोरी के माध्यम से कोड की पठनीयता से संबंधित है। उच्च चक्रवाती जटिलता के साथ कोड (या यहां तक ​​कि सिर्फ उच्च ब्लॉक गहराई) काम करने वाली मेमोरी में रखना मुश्किल है, इसलिए सीधे पढ़ने के लिए अधिक कठिन है।

— थॉमस ओवेन्स

Answer 3

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

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

• कार्यक्रम के भीतर निर्माण की सादगी: आप मान सकते हैं कि एक समारोह में कितने पैरामीटर्स स्वीकार किए जाएंगे। यदि आपके पास> m पैरामीटर के साथ सभी कार्यों का > n % है , तो आप इसे सरल नहीं के रूप में गिन सकते हैं, यह निर्भर करता है कि आप n और m कैसे परिभाषित करते हैं (शायद n = 3 और m = 6?)। मुझे लगता है कि कुछ स्थिर विश्लेषण उपकरण हैं जो इसे माप सकते हैं - मुझे लगता है कि JTest केवल> m मापदंडों के साथ कार्यों को मापा जाता है ।

• आप नेस्टेड छोरों या नियंत्रण संरचनाओं की संख्या को गिनने की कोशिश कर सकते हैं। मुझे लगता है कि यह वास्तव में एक खराब मीट्रिक नहीं है और मुझे लगता है कि इसके लिए एक नाम है (मेरे सिर के ऊपर से याद नहीं कर सकते हैं)। फिर से, मुझे लगता है कि ऐसे उपकरण हैं (फिर से, जेस्ट की तरह) जो इसे माप सकते हैं, एक हद तक।

• आप "प्रतिसक्रियता" को मापने की कोशिश कर सकते हैं। यदि आपके कोड में कोड के बहुत सारे टुकड़े होते हैं , जिन्हें रिफैक्ट किया जा सकता है, लेकिन ऐसा नहीं है , तो शायद यह उतना आसान नहीं है। मुझे उस समय से भी याद है जब मैंने जेस्ट के साथ काम किया था कि उसने इसे भी मापने की कोशिश की थी, लेकिन मुझे याद है कि मैं अक्सर इस मामले में इससे सहमत नहीं था, इसलिए वाईएमएमवी।

• आप अपने सिस्टम के विभिन्न हिस्सों के बीच परतों की संख्या को मापने का प्रयास कर सकते हैं। उदाहरण के लिए: कोड के कितने अलग-अलग टुकड़े डेटाबेस में संग्रहीत होने से पहले वेब फॉर्म से आने वाले डेटा को स्पर्श करेंगे? यह ठीक से मापने के लिए एक मुश्किल हो सकता है ...

Comments

मेरा मानना ​​है कि # 3 को ब्लॉक डेप्थ कहा जाता है। यदि यह निर्णायक नियंत्रण संरचनाएं हैं तो यह साइक्लोमैटिक जटिलता से भी संबंधित है।

— थॉमस ओवेन्स

कोई डाउनवोट स्पष्टीकरण नहीं?

— FrustratedWithFormsDesigner

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

— तर्क

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

— तर्क

@ एसके-तर्क: मुझे लगता है कि मुझे उस "चतुरता" को बुलाया जाना चाहिए, यह मेरा मतलब है। मैं केवल इतना ही कहूंगा कि ?:जब वे 5 गहरे घने होते हैं तो एक समस्या होती है। परतों के लिए, साफ तौर पर अलग-अलग परतें एक दृढ़ परत से बेहतर होती हैं। लेकिन 7 ज्यादातर बेमानी परतों, जब केवल 2 या 3 आवश्यक थे, एक बुरी चीज है।

— FrustratedWithFormsDesigner