कम कोड कैसे लिखें [बंद]

Question

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

मेरा सवाल यह है कि क्या यह ऐसा कुछ है जो सिर्फ अनुभव के साथ आता है या यह कुछ ऐसा है जिसे आप स्पष्ट रूप से उस गुणवत्ता को विकसित करने के लिए कर सकते हैं?

Comments

प्रवृत्ति को प्लॉट करें और देखें कि आप x- अक्ष को कब पार करते हैं ...

मैक्रोज़, मैक्रोज़, मैक्रोज़ को अनिवार्य सूचक: paulgraham.com/avg.html

— vemv

व्यर्थ प्रोग्रामिंग शैली को अपनाकर आप बहुत ही सुरीले, पठनीय कोड उत्पन्न कर सकते हैं। व्यर्थ प्रोग्रामिंग केवल कार्यों को लागू करने से प्रोग्रामिंग है। आप इसे मैप, फिल्टर, कॉनकट, फोल्ड / कम / इंजेक्ट / [लिस्ट कैटामोर्फिज्म के लिए अन्य नाम] आदि जैसे उच्च-क्रम के कार्यों के व्यापक उपयोग से पहचान सकते हैं

— dan_waterworth

-1: यह भेस में आत्म-बधाई की तरह लगता है।

— जिम जी।

मैंने अभी तक पठनीय बिंदु मुक्त कोड नहीं देखा है। किसी भी महत्वपूर्ण पुस्तकालय में नहीं।

— साइमन बर्गोट

Answer 1

मैं यह कहूंगा कि यह पूरी तरह से ऐसा कुछ है जो समय और अनुभव के साथ आता है, लेकिन आप पा सकते हैं कि यदि आप कुछ कार्य अधिक सुस्पष्ट भाषाओं के साथ करते हैं तो आप उस गुणवत्ता को अपनी नियमित कामकाजी भाषाओं में वापस लाते हैं।

निश्चित रूप से रूबी के साथ एक या दो साल काम करने के बाद मैंने पाया कि मेरा सी # बहुत ज्यादा टैपर है। मुझे लगता है कि अगर मैं कार्यात्मक प्रोग्रामिंग को बेहतर ढंग से समझ रहा होता (एक निरंतर महत्वाकांक्षा) तो शायद मैं इससे और अधिक लेता।

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

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

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

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

यदि आप सोच रहे हैं कि क्या कुछ करने का एक बेहतर तरीका है, तो शायद है और यह हमेशा यह जानने के लायक है कि चीजों को बेहतर कैसे किया जाए।

Comments

हां, मेरी राय में, निजी एक-लाइन कार्यों का एकमात्र कारण

चूंकि मेरे पास उन कार्यों के अधिक होने के कारण मेरी कक्षाओं में कोड की पंक्तियों की संख्या में काफी कमी आई है और यह एक बहुत ही भद्दा और स्पष्ट दिखता है।

— ग्लेनट्रॉन

थोड़ा विरोधाभास की तरह लगता है, अधिक कार्य लेकिन कम लाइनें, लेकिन शायद मैं अपने कोड में भी एक ही प्रवृत्ति देख सकता हूं .. मुझे इस बारे में सोचना होगा ....

क्या आपके पास इन दिशानिर्देशों का कोई और पालन किया जा सकता है? लगता है जैसे वे एक युवा देव के लिए उपयोगी हो सकते हैं जैसे कि खुद को।

— स्टुअर्टमक्लर्क

@stuartmclark - मैंने कुछ और जोड़े हैं, हालांकि मुझे संदेह है कि वहाँ बहुत अधिक नहीं है जो आपने कहीं और नहीं सुना होगा।

— ग्लेनट्रॉन

Answer 2

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

एक सामान्य उत्तर मुझे मिलता है जब मैं पूछता हूं कि लोगों ने अपने स्वयं के ORM, या अपने स्वयं के लॉगिंग इंजन, या अपने स्वयं के UI घटकों या अपने स्वयं के सब कुछ क्यों किया:

लेकिन हमारा बेहतर है

मेरा मानना ​​है कि यह कथन अधिकांश मामले के लिए सही है, लेकिन ज्यादातर मामलों में आरओआई पर नकारात्मक प्रभाव बहुत अधिक है। आप माँ सबसे अच्छे व्यंजन बनाती हैं? लेकिन आप माँ को घर आने और रोज़ तैयार करने के लिए नहीं कह सकते।

इसलिए मुझे लगता है कि डेवलपर्स को अपनी पसंद के वित्तीय प्रभाव में दिलचस्पी लेनी चाहिए। उनमें से कुछ हैं:

• घटक के निर्माण के लिए आवश्यक अतिरिक्त कार्य
• इसे सीखने के लिए नए काम करने वालों के लिए अतिरिक्त काम
• इसे बनाए रखने के लिए बहुत बड़ा काम

मुझे लगता है कि वे घटक विक्रेता आपकी विस्तारित टीम हैं जो आपके द्वारा निर्मित, बनाए रखने और अपने आप को बेहतर बनाने के लिए भुगतान किए गए एक छोटे से अंश के लिए आपके लिए काम कर रहे हैं।

यह पूरी कंपनी के लिए हमारे अहंकार की संतुष्टि को अधिकतम करने के बजाय अधिकतम आरओआई के लिए बेहतर है ;) आपकी कंपनी को जितना अधिक पैसा मिलेगा, आपके कार्य की स्थिति और वेतन बढ़ने की संभावना उतनी ही अधिक होगी।

Comments

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

कभी-कभी यह आपके द्वारा दिए गए ढांचे के ज्ञान की कमी के कारण होता है। मैंने अपनी खुद की पाथ क्लास भी लिखी थी जब मैंने .NET के साथ काम करना शुरू किया था, तब मैंने System.IO.Path क्लास को कुछ दिनों बाद

मैंने अपनी मॉम की स्पेगेटी को प्राथमिकता दी, लेकिन जार में सामान काफी अच्छा था। यह वास्तव में आवश्यकताओं के प्रभारी को उबालता है। यदि वे 85% समाधान के लिए व्यवस्थित नहीं होते हैं, तो आपके पास कोई विकल्प नहीं है।

— जेफ़ओ

मेरी माँ स्पेगेटी को बहुत बेहतर करती है कि तुम्हारा।

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

— ब्लेयरहिप्पो

Answer 3

मेरी राय में, कम कोड लिखना कई तरीकों से किया जा सकता है:

• आपको इसकी आवश्यकता नहीं है । कुछ ऐसा कोड न करें जिसकी आपको अभी तक आवश्यकता नहीं है। कोड केवल आवश्यकताओं को राज्य। इस तरह, हम लिखने के लिए आवश्यक कोड कम कर देंगे।

• अपने आप को दोहराएं नहीं । मेरा मानना ​​है कि सीएमएस, फ्रेमवर्क या थर्ड पार्टी लाइब्रेरी का उपयोग करना DRY सिद्धांत को लागू करने का एक तरीका है।

• अमूर्तन । और अंतिम लेकिन कम से कम नहीं, अमूर्त प्रोग्रामिंग कोड को बहुत कम कर सकती है। कोड को अलग करने से कोड का पुन: उपयोग करने का मौका अधिक हो जाएगा क्योंकि यह दोहराव को कम करता है।

Answer 4

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

सुनिश्चित करें कि आपको समस्या की अच्छी समझ है। इसका विश्लेषण करें, समाधान (ओं) के साथ आएं, पेशेवरों और विपक्षों का वजन करें (निश्चित रूप से "समाधानों का एक 's'" समस्या से समस्या में बहुत भिन्न होगा - बस यहां आम तौर पर बोल रहा हूं।) फिर चुने हुए समाधान का कार्यान्वयन होता है, जो। वह जगह है जहां भाषा की आपकी समझ (और यदि लागू होती है), तो खेल में आ जाएगी।

Comments

समाधान बनाम प्रोग्रामिंग तैयार करने में आप कितना समय देते हैं?

यह समस्या पर निर्भर करता है, निश्चित रूप से। मैं यहाँ दिनों की बात नहीं कर रहा हूँ। आमतौर पर कोडिंग से पहले सोचने में थोड़ा समय व्यतीत होता है। यह वास्तव में कर रहे समय के बारे में नहीं है या तो यह एक अच्छा के साथ आ रहा है - और लंबे समय के समाधान में आदर्श रूप से बनाए रखने योग्य है। मैं गंदे समाधान के लिए भद्दा कोड का उत्पादन कर सकता हूँ ठीक है - कोई भी ऐसा कर सकता है।

— मेटलमेकेस्टर

Answer 5

प्रोग्रामिंग की पूरी कला को नीचे आने के लिए कहा जा सकता है।

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

Answer 6

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

Comments

इसलिए मुझे अपने कोड को फिर से लिखना चाहिए और इसे कम करने के लिए एक रीफ़्रैक्टर करना चाहिए कि कैसे कम कोड लिखें या जैसा कि पीट कहता है, terser कोड?

@Gorgen - यदि आपके पास समय है या आप एक घंटे पहले लिखे किसी भी कोड को देख सकते हैं। कभी-कभी SO पर एक उदाहरण प्रस्तुत करना आपको वापस जाने और अपने कोड में कुछ बदलाव करने के लिए प्रेरित कर सकता है।

— जेएफओ

Answer 7

1. अपने पुराने लंबे घुमावदार कोड पर वापस जाएं
2. इसे संस्करण नियंत्रण में रखें,
3. यह सुनिश्चित करने के लिए कुछ परीक्षण लिखें कि नए बग को शुरू नहीं किया जाना चाहिए,
4. पुनर्लेखन।

बार-बार विज्ञापन परिवाद। और नरक में आपका स्वागत है।

Answer 8

परीक्षण प्रेरित विकास मदद कर सकता है। इसका उपयोग करते हुए, आप केवल उस परीक्षा को पास करने के लिए आवश्यक न्यूनतम कोड लिखते हैं।

Comments

उस संदर्भ में, सुविधाओं के संदर्भ में न्यूनतम का मतलब लंबाई है, लंबाई नहीं।

— वीएमवी