किस बिंदु पर संक्षिप्तता अब एक गुण नहीं है?

102

हाल ही के बग फिक्स ने मुझे टीम के अन्य सदस्यों द्वारा लिखे गए कोड पर जाने की आवश्यकता थी, जहां मुझे यह मिला (यह C # है):

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

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

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

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

_{जातियों का कारण एंटिटी फ्रेमवर्क है। डीबी को इन्हें अशक्त प्रकारों के रूप में संग्रहीत करने की आवश्यकता है। दशमलव? C # में दशमलव के बराबर नहीं है और इसे डाले जाने की आवश्यकता है।}

c# coding-style code-quality clean-code

— बॉब Tway
स्रोत

153

जब संक्षिप्तता पठनीयता को रौंद देती है।

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

27

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

— एरिक लिपर्ट

29

विशेष रूप से, यह विचित्र लगता है कि कॉस्टइन को दशमलव में शून्य करने के लिए इसकी तुलना करना आवश्यक है, लेकिन कॉस्टऑट नहीं; ऐसा क्यों है? पृथ्वी पर क्या है कॉस्ट इन का प्रकार यह केवल दशमलव में कास्टिंग द्वारा शून्य से तुलना की जा सकती है। और CostOut CostIn के समान प्रकार का क्यों नहीं है?

— एरिक लिपिपर्ट

12

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

— एरिक लिपर्ट

5

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

— सोलोमनऑफ का सीक्रेट

163

मौजूदा शोध के बारे में आपके प्रश्न का उत्तर देने के लिए

लेकिन उस बिंदु को पहचानने पर कुछ भी लिखा या शोध किया गया है जहां कोड संक्षिप्तता के लिए प्रयास करना उपयोगी होना बंद हो जाता है और समझ में बाधा बन जाता है?

हां, इस क्षेत्र में काम हुआ है।

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

साइक्लोमैटिक जटिलता Lines कोड की स्रोत लाइनें ( SLOC )

आपके कोड उदाहरण में, यह अनुपात बहुत अधिक है, क्योंकि सब कुछ एक पंक्ति में संकुचित हो गया है।

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

संपर्क

यहाँ कुछ संदर्भ हैं यदि आप रुचि रखते हैं:

मैककेबे, टी। और ए। वॉटसन (1994), सॉफ्टवेयर जटिलता (क्रॉसटॉक: द जर्नल ऑफ़ डिफेंस सॉफ्टवेयर इंजीनियरिंग)।

वॉटसन, एएच, और मैककेबे, टीजे (1996)। स्ट्रक्चर्ड टेस्टिंग: साइक्लोमैटिक कॉम्प्लेक्सिटी मेट्रिक (NIST स्पेशल पब्लिकेशन 500-235) का उपयोग करके एक टेस्टिंग मेथोलॉजी। 14 मई, 2011 को मैककेबे सॉफ्टवेयर वेब साइट से लिया गया: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

रोसेनबर्ग, एल।, हैमर, टी।, शॉ, जे। (1998)। सॉफ्टवेयर मेट्रिक्स और विश्वसनीयता (आईईईई अंतर्राष्ट्रीय संगोष्ठी सॉफ्टवेयर विश्वसनीयता इंजीनियरिंग पर कार्यवाही)। 14 मई, 2011 को पेन स्टेट यूनिवर्सिटी की वेब साइट से प्राप्त: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&hl=hi

मेरी राय और समाधान

व्यक्तिगत रूप से, मैंने कभी भी संक्षिप्तता का मूल्य नहीं लिया है , केवल पठनीयता है। कभी-कभी संक्षिप्तता पठनीयता में मदद करती है, कभी-कभी ऐसा नहीं होता है। जो अधिक महत्वपूर्ण है वह यह है कि आप राइट-ओनली कोड (WOC) के बजाय वास्तव में स्पष्ट कोड (ROC) लिख रहे हैं ।

बस मज़े के लिए, यहाँ मैं इसे कैसे लिखूंगा, और अपनी टीम के सदस्यों से इसे लिखने के लिए कहूंगा:

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

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

— जॉन वू
स्रोत

4

मुझे वास्तव में शून्य से कम के मामले में गार्ड क्लॉज पसंद है। एक टिप्पणी के योग्य हो सकता है: लागत शून्य से कम कैसे हो सकती है, क्या विशेष मामला है?

— user949300

22

+1। मैं शायद कुछ ऐसा if ((costIn < 0) || (costOut < 0)) throw new Exception("costs must not be negative");

— Doc Brown

13

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

— एरिक लिपिपर्ट

12

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

— जॉन वू

30

"व्यक्तिगत रूप से, मैंने कभी भी संक्षिप्तता नहीं की है , केवल पठनीयता। कभी-कभी संक्षिप्तता पठनीयता में मदद करती है, कभी-कभी ऐसा नहीं होता है।" बहुत बढ़िया बिंदु। इसके लिए सिर्फ +1। मुझे आपका कोड समाधान भी पसंद है।

— वाइल्डकार्ड

49

ब्रेविटी तब अच्छी होती है जब यह उन चीज़ों के आस-पास अव्यवस्था को कम करता है, लेकिन जब यह थकाऊ हो जाता है , तो बहुत अधिक प्रासंगिक डेटा को बहुत आसानी से पालन करने के लिए पैकिंग करना, फिर संबंधित डेटा स्वयं अव्यवस्थित हो जाता है और आपको एक समस्या होती है।

इस विशेष मामले में, जातियों को decimalबार-बार दोहराया जा रहा है; यह संभवतः बेहतर होगा कि इसे कुछ इस तरह से लिखा जाए:

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

अचानक तर्क वाली रेखा बहुत छोटी हो जाती है और एक क्षैतिज रेखा पर फिट हो जाती है, इसलिए आप बिना स्क्रॉल किए सब कुछ देख सकते हैं, और अर्थ बहुत अधिक स्पष्ट रूप से स्पष्ट है।

— मेसन व्हीलर
स्रोत

1

मैं शायद आगे चला गया और ((decOut - decIn ) / decOut) * 100दूसरे चर के लिए बाहर निकाल दिया जाएगा।

— FrustratedWithFormsDesigner

9

असेंबलर ज्यादा स्पष्ट था: प्रति पंक्ति केवल एक ऑपरेशन। रवींद्र!

2

@FrustratedWithFormsDesigner मैं भी एक कदम आगे जाकर कोष्ठक में सशर्त जाँच लपेटूंगा।

— क्रिस क्रेफ़िस

1

@FrustratedWithFormsDesigner: यह सशर्त डिविज़न-बाय-ज़ीरो चेक ( CostOut > 0) को बायपास करने से पहले निकालने वाला है , इसलिए आपको सशर्त का विस्तार एक ifस्टेटमेंट में करना होगा। ऐसा नहीं है कि इसमें कुछ भी गलत है, लेकिन यह केवल एक स्थानीय परिचय की तुलना में अधिक वाचालता जोड़ता है।

— वचर्जिन

1

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

— वॉलफ्रैट

7

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

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

— supercat
स्रोत

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

— लोरेन Pechtel

@ लोरेनपेकटेल: यह देखते हुए कि एक Decimalडाली जिस पर सटीक बैठती है , वह प्रश्न में मूल्य की भयावहता पर निर्भर करता है, मुझे व्यावसायिक नियमों की कल्पना करना कठिन लगता है, जो वास्तव में व्यवहार करने के लिए जा रहे हैं।

— सुपरकैट

1

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

— लोरेन Pechtel

1

@ लॉरेनपेकटेल: मेरे अंतिम बिंदु को स्पष्ट करने के लिए: एक निश्चित-बिंदु प्रकार इस बात की गारंटी दे सकता है कि x + yy या तो अतिप्रवाह या उपज y। Decimalप्रकार नहीं है। 1.0d / 3.0 के मान में दशमलव के दाईं ओर अधिक अंक होंगे, बड़ी संख्या का उपयोग करते समय बनाए रखा जा सकता है। इसलिए एक ही बड़ी संख्या को जोड़ना और घटाना सटीक नुकसान का कारण होगा। फिक्स्ड-पॉइंट प्रकारों को आंशिक गुणन या विभाजन के साथ परिशुद्धता खो सकती है, लेकिन इसके अलावा, घटाव, गुणा, या विभाजन-शेष के साथ (जैसे 1.00 / 7 0. 0.14 शेष 0.2 है; 1.00 डिव 0.15 6 शेष 0.10 है)।

— सुपरकैट

1

@ हल्क: हाँ, बिल्कुल। मैं बहस कर रहा था कि क्या x + yy yielding x, x + yx yielding y, या x + yxy का उपयोग किया जाए, और पहले दो में मिश-मॉशिंग को समाप्त किया। यह महत्वपूर्ण है कि फिक्स्ड-पॉइंट प्रकार इस बात की गारंटी दे सकते हैं कि संचालन के कई अनुक्रम कभी भी किसी भी परिमाण की अवांछित गोल त्रुटियों का कारण नहीं बनेंगे । यदि कोड अलग-अलग तरीकों से एक साथ चीजों को जोड़ता है, तो यह सत्यापित करने के लिए कि टोटल मिलान (जैसे स्तंभ उप-योग के योग की तुलना पंक्ति उप योग) से किया जाता है, तो परिणाम ठीक-ठीक बराबर आने से बेहतर होता है कि वे "पास" से बाहर आ जाएं।

— सुपरकैट

5

मैं उस कोड को देखता हूं और पूछता हूं कि "लागत 0 (या कम) कैसे हो सकती है?"। क्या विशेष मामला इंगित करता है? कोड होना चाहिए

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

मैं यहां नामों के रूप में अनुमान लगा रहा हूं: परिवर्तन BothCostsAreValidProductsऔर NO_PROFITउपयुक्त रूप में।

— user949300
स्रोत

बेशक, लागत शून्य हो सकती है (सोचो क्रिसमस प्रस्तुत करता है)। और नकारात्मक ब्याज दरों के समय में नकारात्मक लागत या तो बहुत आश्चर्यचकित नहीं होनी चाहिए और कम से कम कोड से निपटने के लिए तैयार रहना चाहिए (और त्रुटियों को फेंककर)

— हेगन वॉन एटिजन

अपने सही रास्ते पर।

— danny117

यह मूर्खतापूर्ण है। if (CostIn <= 0 || CostOut <= 0)पूरी तरह से ठीक है।

— माइल्स रूट

बहुत कम पठनीय। चर नाम भयानक है (BothCostsAreValid बेहतर होगा। उत्पादों के बारे में यहां कुछ भी नहीं है)। लेकिन यह भी पठनीयता के लिए कुछ भी नहीं जोड़ता है, क्योंकि सिर्फ CostIn की जाँच, CostOut ठीक है। यदि आप जिस अभिव्यक्ति का परीक्षण कर रहे हैं उसका अर्थ स्पष्ट नहीं है, तो आप एक सार्थक नाम के साथ एक अतिरिक्त चर पेश करेंगे।

— gnasher729

5

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

कम से कम काम के साथ व्यावसायिक आवश्यकताओं को पूरा करें
बग से बचें
हमें भविष्य में परिवर्तन करने की अनुमति दें जो 1 और 2 को पूरा करते रहें

ये लक्ष्य हैं। किसी भी डिजाइन सिद्धांत या विधि (यह चुंबन हो, YAGNI, TDD, ठोस, सबूत, प्रकार सिस्टम, गतिशील metaprogramming आदि) केवल हद तक वे हमें इन लक्ष्यों को प्राप्त करने में मदद करने पुण्य कर रहे हैं।

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

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

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

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

तो समस्या संक्षिप्तता या उसके अभाव की नहीं है, समस्या बार-बार तर्क और चिंताओं के टकराव को बनाए रखने के लिए है।

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

— JacquesB
स्रोत

1

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

— gnasher729

3

ब्रह्मचर्य कोई गुण नहीं है। पठनीयता का गुण है।

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

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

— Agent_L
स्रोत

2

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

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

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(संपादित करें: यह अन्य उत्तर के समान कोड है, इसलिए आप वहां जाते हैं।)

मैं टर्नरी ऑपरेटर का प्रशंसक हूं ? :, इसलिए मैं इसे छोड़ दूंगा ।

— पॉल ब्रिंकले
स्रोत

5

टर्नरीज़ को पढ़ना मुश्किल है, खासकर अगर रिटर्न वैल्यू में सिंगल वैल्यू या वेरिएबल से परे कोई भाव हो।

— आलमो

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

— पॉल ब्रिंकले

1

वाकई यकीन नहीं होता। मैंने आपको निराश नहीं किया। मुझे टर्नरीज़ पसंद नहीं है क्योंकि यह स्पष्ट नहीं है कि दोनों ओर से क्या है :। if-elseअंग्रेजी की तरह पढ़ता है: याद नहीं कर सकता कि इसका क्या मतलब है।

— अल्मो

FWIW मुझे संदेह है कि आप डाउनवोट हो रहे हैं क्योंकि यह मेसन व्हीलर के लिए एक बहुत ही समान उत्तर है, लेकिन उनका पहला मिल गया।

— बॉब तेव

1

टर्राने वाले की मौत !! (इसके अलावा, टैब के लिए मौत, न ही रिक्त स्थान और कोई ब्रैकेटिंग और इंडेंटेशन मॉडल, सिवाय ऑलमैन के (वास्तव में, डोनाल्ड (टीएम) ने ट्वीट किया है कि ये पहले तीन कानून होंगे जो वह 20 तारीख को अधिनियमित करते हैं)

— मावी

2

पठनीयता के ऊपर लगभग सभी उत्तरों की तरह हमेशा आपका प्राथमिक लक्ष्य होना चाहिए। हालाँकि, मैं यह भी सोचता हूं कि चर और नई लाइनें बनाने के लिए इसे प्राप्त करने के लिए स्वरूपण एक अधिक प्रभावी तरीका हो सकता है।

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

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

— backpackcoder
स्रोत

4

जातियों का कारण एंटिटी फ्रेमवर्क है। डीबी को इन्हें अशक्त प्रकारों के रूप में संग्रहीत करने की आवश्यकता है। डबल? C # में डबल के बराबर नहीं है और इसे डाले जाने की आवश्यकता है।

— बॉब Tway

2

@MattThrower आपका मतलब है decimal, है ना? double! = decimal, एक बड़ा अंतर है।

— Pinkfloydx33

1

@ pinkfloydx33 हाँ! एक फोन पर केवल आधा मस्तिष्क लगे हुए टाइपिंग :)

— Bob Tway

मुझे अपने छात्रों को यह समझाना होगा कि SQL डेटाटाइप्स प्रोग्रामिंग भाषाओं में उपयोग किए जाने वाले प्रकारों से भिन्न हैं। मैं हालांकि उन्हें क्यों नहीं समझा पा रहा हूं । "मुझे नहीं पता!" "छोटा एंडियन!"

3

मुझे यह बिल्कुल भी पढ़ने योग्य नहीं लगता।

— आलमो

1

मेरे लिए, ऐसा लगता है कि यहाँ पठनीयता के साथ एक बड़ी समस्या स्वरूपण के पूर्ण अभाव में है।

मैं इसे इस तरह लिखूंगा:

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

इस पर निर्भर करता है कि प्रकार CostInऔर CostOutएक फ्लोटिंग-पॉइंट प्रकार है या एक अभिन्न प्रकार है, कुछ कास्ट भी अनावश्यक हो सकते हैं। इसके विपरीत floatऔर double, अभिन्न मूल्यों को स्पष्ट रूप से बढ़ावा दिया जाता है decimal।

— फेलिक्स डॉमबेक
स्रोत

मुझे यह देखकर खेद हुआ कि यह बिना किसी स्पष्टीकरण के अस्वीकृत कर दिया गया था, लेकिन मुझे लगता है कि यह बैकपेकॉड्स के उत्तर के समान है , जिसमें उनकी कुछ टिप्पणी है, इसलिए मुझे लगता है कि यह उचित था।

— PJTraill 20

@PJTraill मुझे याद आया होगा कि, यह वास्तव में लगभग समान है। हालांकि, मैं दृढ़ता से नई लाइनों पर ऑपरेटरों को रखना पसंद करता हूं, यही वजह है कि मैं अपने संस्करण को खड़ा होने दूंगा।

— फेलिक्स डॉम्बेक

मैं ऑपरेटरों के बारे में सहमत हूं, जैसा कि मैंने दूसरे उत्तर पर एक टिप्पणी में कहा था - मुझे यह पसंद नहीं था कि आपने इसे पसंद किया था।

— PJTraill

0

कोड को जल्दी में लिखा जा सकता है, लेकिन मेरी दुनिया में उपरोक्त कोड को अधिक बेहतर चर नामों के साथ लिखा जाना चाहिए।

और अगर मैं कोड को सही ढंग से पढ़ता हूं तो यह एक स्थूल गणना करने की कोशिश कर रहा है।

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

— थॉमस कोएले
स्रोत

3

आप शून्य रिटर्न शून्य से विभाजन खो दिया है।

— danny117

1

और यही कारण है कि यह किसी और के कोड को रिफलेक्टर करने के लिए मुश्किल है जो संक्षिप्तता के लिए अधिकतम है और क्यों यह समझाने के लिए अतिरिक्त टिप्पणियां करना अच्छा है कि क्यों / कैसे काम करते हैं

— रुडोल्फ ओला

0

मैं मान रहा हूं कि CostIn * CostOut पूर्णांक हैं
यह है कि मैं इसे कैसे लिखूंगा
M (धन) दशमलव है

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

— paparazzo
स्रोत

1

उम्मीद है कि वे दोनों नकारात्मक विचार नहीं हैं: p

— Walfrat

2

क्या शून्य द्वारा विभाजित अभी भी वहाँ है?

— danny117

@ danny117 जब संक्षिप्तता गलत उत्तर देती है तो यह दूर हो गई है।

— paparazzo

प्रश्न को अपडेट करना और उसे सक्रिय नहीं करना चाहते हैं। 100M और 0M दशमलव को बल देते हैं। मुझे लगता है कि (CostOut - CostIn) को पूर्णांक गणित के रूप में प्रदर्शित किया जाएगा और फिर अंतर को दशमलव पर रखा जाएगा।

— paparazzo

0

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

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

— रुडोल्फ ओलाह
स्रोत

1

यह वह जगह है जहाँ सॉफ्टवेयर इंजीनियरिंग प्रथाओं और सिद्धांतों खेलने में आते हैं। गैर-कार्यात्मक आवश्यकताएं

— हेंज़ोलो

0

ब्रेविटी अब कोई गुण नहीं है

शून्य के लिए पूर्व जांच के बिना विभाजन है।
नल की कोई जांच नहीं है।
कोई सफाई नहीं है।
TRY CATCH बनाम खाद्य श्रृंखला को फेंकता है जहां त्रुटि को नियंत्रित किया जा सकता है।
असिंक्रोनस कार्यों के पूरा होने के क्रम के बारे में अनुमान लगाया जाता है
भविष्य में पुनर्निर्धारण के बजाय देरी का उपयोग करने वाले कार्य
अनावश्यक IO का उपयोग किया जाता है
आशावादी अद्यतन का उपयोग नहीं कर रहा है

— danny117
स्रोत

जब बहुत लंबा जवाब नहीं है।

1

ठीक है, यह एक टिप्पणी है, एक जवाब नहीं होना चाहिए था। लेकिन वह नया आदमी है, इसलिए कम से कम समझाता है; बस नीचे मत भागो और भाग जाओ! आपका स्वागत है, डैनी। मैंने एक डाउनवोट रद्द कर दिया, लेकिन अगली बार इसे एक टिप्पणी :-)

— मग

2

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

— danny117

स्वागत के लिए धन्यवाद @ मेवग मैं चेक के लिए संकेत देना चाहता हूं कि मैं संक्षिप्त कोड में सबसे अधिक समस्याओं का सामना क्यों कर रहा हूं।

— danny117

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

— danny117

0

यदि यह सत्यापन इकाई परीक्षणों को पारित कर रहा था, तो यह ठीक होगा, यदि एक नया चश्मा जोड़ा गया था, तो एक नया परीक्षण या एक बढ़ाया कार्यान्वयन की आवश्यकता थी, और यह कोड की थकाऊता "असंगत" करने के लिए आवश्यक था, जब कि शामिल है समस्या पैदा होगी।

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

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

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

यदि आप इस तरह के कोड को देखना पसंद नहीं करते हैं, तो टीम को कार्यान्वयन मानकों और सम्मेलनों पर समझौते में लाने की कोशिश करें और इसे लिख लें और सम्मेलन को मान्य करने के लिए यादृच्छिक कोड समीक्षा या स्पॉट चेक करें।

— hanzolo
स्रोत