एक अच्छा प्रोग्रामर का कोड कैसा दिखता है? [बन्द है]

Question

मैं एक शौक़ीन प्रोग्रामर हूँ (एक्सेल को तेज़ बनाने के लिए VBA के साथ शुरू) और VB.NET / C # .NET के साथ काम कर रहा हूँ और ADO.NET सीखने की कोशिश कर रहा हूँ।

प्रोग्रामिंग का एक पहलू जिसने मुझे हमेशा निराश किया है वह है 'अच्छा' कैसा दिखता है? मैं एक पेशेवर नहीं हूं, इसलिए इसकी तुलना बहुत कम है। क्या एक बेहतर प्रोग्रामर बनाता है? क्या यह:

• उन्हें दी गई भाषा में सभी वस्तुओं / वर्गों / विधियों की बेहतर समझ है?
• उनके कार्यक्रम अधिक कुशल हैं?
• उनके कार्यक्रमों का डिज़ाइन बेहतर प्रलेखन, कार्यों के लिए नामों का अच्छा विकल्प आदि के मामले में बहुत बेहतर है?

एक और तरीका रखो, अगर मुझे एक पेशेवर प्रोग्रामर के कोड को देखना है, तो पहली चीज क्या है जो मैं उनके कोड के बारे में नोटिस करूंगा? उदाहरण के लिए, मैं Wrox प्रेस द्वारा 'प्रोफेशनल ASP.NET' जैसी किताबें पढ़ता हूं। क्या उस पुस्तक 'वर्ल्ड क्लास' में कोड उदाहरण हैं? क्या वह शिखर है? क्या कोई भी टॉप गन प्रोग्रामर उस कोड को देखेगा और यह सोचेगा कि यह अच्छा कोड था?

Answer 1

नीचे दी गई सूची व्यापक नहीं है, लेकिन ये चीजें हैं जो मैंने आपके प्रश्न पर विचार करने में सोचा था।

• अच्छा कोड सुव्यवस्थित है। कक्षाओं में डेटा और संचालन एक साथ फिट होते हैं। वर्गों के बीच बाहरी निर्भरता नहीं हैं। यह "स्पेगेटी" की तरह नहीं दिखता है।

• अच्छा कोड टिप्पणियां बताती हैं कि चीजें क्यों नहीं की जाती हैं जो किया जाता है। कोड ही बताता है कि क्या किया गया है। टिप्पणियों की आवश्यकता न्यूनतम होनी चाहिए।

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

• अच्छा कोड अच्छी तरह से परीक्षण किया जाता है। टेस्ट कोड के निष्पादन योग्य विनिर्देश और इसके उपयोग के उदाहरणों के रूप में कार्य करते हैं।

• अच्छा कोड "चतुर" नहीं है। यह चीजों को सरल, स्पष्ट तरीके से करता है।

• अच्छा कोड छोटे में विकसित किया गया है, गणना की इकाइयों को पढ़ने में आसान है। इन इकाइयों को पूरे कोड में पुन: उपयोग किया जाता है।

मैंने इसे अभी तक पढ़ा नहीं है, लेकिन इस विषय पर मैं जिस पुस्तक को पढ़ने की योजना बना रहा हूं, वह है रॉबर्ट सी। मार्टिन का क्लीन कोड ।

Comments

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

— Stein Stesmul

अच्छा कोड "चतुर" नहीं है। यह चीजों को सरल, स्पष्ट तरीके से करता है। सबसे अच्छा हिस्सा

— nawfal

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

— 0x1mason

@tvanfosson क्या आपने अब तक किताब पढ़ी है? :-)

— नटन स्ट्रैपल

मैंने उस किताब से बहुत कुछ सीखा है और इसके पढ़ने के लिए उबाऊ नहीं है।

— रेगि

Answer 2

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

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

आपके द्वारा कोड के साथ गड़बड़ करने के बाद तीसरी बात जो आप देखेंगे, वह यह है कि तर्क का पालन करना आसान है, संशोधित करना आसान है - और इसलिए आसानी से बनाए रखा जा सकता है।

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

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

Comments

इसे बहुत प्रभावी ढंग से सारांशित करने के लिए +1। एक और चीज जो जोड़ी जा सकती है वह यह है कि बहुत सी नेस्टेड शाखाओं से बचना। संभवतः दो स्तर स्वीकार्य हैं उसके बाद इसका पालन करना बहुत कठिन हो जाता है।

— नवीन

आप सही हे। मैंने इसे जोड़ने के बारे में सोचा था लेकिन सोचा कि यह बहुत विशिष्ट हो सकता है

— एरन गैपरिन

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

— प्रात: काल

मैं "छोटे फ़ंक्शंस" पर बहुत अधिक जोर नहीं दूंगा, या तो एक लक्ष्य के रूप में या परिणामस्वरूप। बहुत से छोटे कार्य उतने ही कठिन हैं जितना कि अपारदर्शी कोड के पृष्ठों का पालन करना।

— स्टेटिक्सन

हालांकि कभी-कभी अपरिहार्य होते हैं, जब मैं लंबे तरीकों को देखता हूं तो मुझे लगता है "क्या यह विधि बहुत कुछ करने की कोशिश कर रही है? कैसे तर्क के कुछ ब्लॉकों को सार्थक रूप से नामित विधियों के साथ बदलने के बारे में?" मेरा मानना ​​है कि इस तरह के तरीकों से बना लॉजिक एक बार में सभी लॉजिक को पचाने की तुलना में बहुत आसान है

— Eran Galperin

Answer 3

फाउलर का उद्धरण, पठनीयता का योग:

कोई भी मूर्ख कोड लिख सकता है जिसे कंप्यूटर समझ सकता है।
अच्छे प्रोग्रामर कोड लिखते हैं जो मनुष्य समझ सकते हैं।

'बहुत कहा।

Comments

वाह +1, लघु और मधुर होने के लिए

— devsaw

खैर, वहाँ हमेशा पर्ल में लिखा सभी कोड चला जाता है।

— क्या मैं

जो कुछ भी मैं अपने LAB TEACHER लिखता हूं वह कभी नहीं समझें: p

— प्रकाश बाला

Answer 4

व्यक्तिगत रूप से, मुझे टिम पीटर्स द्वारा "द ज़ेन ऑफ़ पायथन" उद्धृत करना होगा । यह पायथन प्रोग्रामर्स को बताता है कि उनका कोड कैसा दिखना चाहिए, लेकिन मुझे लगता है कि यह मूल रूप से सभी कोड पर लागू होता है।

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

Comments

केवल "एक ही होना चाहिए - और अधिमानतः केवल एक - स्पष्ट तरीका यह करना चाहिए।" स्पष्ट तरीका समस्या के बारे में आपके सोचने के तरीके पर निर्भर करता है। यह अनिवार्य बनाम कार्यात्मक है।

— grom

"फ्लैट नेस्टेड से बेहतर है" बहुत संदिग्ध है।

— 54होर मे

Answer 5

कोड कविता है।

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

कोरोलरी पर एक अनुसरण:

पाठक आपको कोड निर्माण की तारीख से समय n पर होगा। पाठक के लिए कोड लिखने की अदायगी n का एक नीरस रूप से बढ़ता हुआ कार्य है। पहली बार आपके कोड को देखने वाला पाठक n == अनंत द्वारा इंगित किया गया है।

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

एक दूसरा कोरोलरी:

पाठक के लिए विचार के बिना लिखे गए कोड को समझना या उपयोग करना अनावश्यक रूप से कठिन हो सकता है। जब पाठक के लिए विचार एक निश्चित सीमा से नीचे चला जाता है, तो पाठक कोड को फिर से लिखने से प्राप्त मूल्य की तुलना में कोड से कम मूल्य प्राप्त करता है। जब ऐसा होता है तो पिछले कोड को फेंक दिया जाता है और, दुख की बात है कि पुनर्लेखन के दौरान बहुत काम दोहराया जाता है।

एक तीसरा कोरोलरी:

कोरोलरी दो को खुद को कई बार दोहराने के लिए जाना जाता है क्योंकि खराब लिखित दस्तावेज के एक दुष्चक्र में मजबूरन फिर से लिखना पड़ता है।

Comments

अपवाद के साथ कि कोड के साथ, यह स्पष्ट होना चाहिए कि आपका क्या मतलब है, बिल्कुल। +1, हालांकि

— रिक

एक बार रिचर्ड गेब्रियल ने प्रोग्रामर्स को अपनी लेखन कविता के बारे में बात करते हुए देखा। संबंध बनाने के लिए मुझे कुछ समय लगा।

— थोरबजोरन राव एंडरसन

Answer 6

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

लब्बोलुआब यह है कि इसका मतलब अलग-अलग लोगों के लिए अलग-अलग चीजें हैं। मैं किसी और से नफरत करने वाले अच्छे कोड के रूप में क्या लेबल लगा सकता हूं। अच्छे कोड में कुछ सामान्य लक्षण होंगे जो मुझे लगता है कि मैंने ऊपर पहचाना है।

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

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

Answer 7

पुस्तक कोड पूरा पढ़ें। यह बहुत सारे विचारों के बारे में बताता है कि कैसे संरचना कोड और ऐसा करने के कारण। इसे पढ़कर शॉर्ट-सर्किट को अपना समय खराब से अच्छा बताने के लिए आवश्यक अनुभव प्राप्त करना चाहिए।

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Answer 8

अब लगभग 10 वर्षों से स्वयं प्रोग्रामिंग कर रहा हूं और दूसरों के साथ काम कर रहा हूं, मैं बिना पूर्वाग्रह के कह सकता हूं कि एक अच्छे प्रोग्रामर और एक औसत प्रोग्रामर कोड के बीच कोई अंतर नहीं है

एक सक्षम स्तर पर सभी प्रोग्रामर:

• सही ढंग से टिप्पणी करें
• संरचना कुशल से
• साफ-सफाई से दस्तावेज

मैं एक बार एक सहकर्मी से कहता हूं " मैं हमेशा बहुत तार्किक और तर्कसंगत सोच वाला हूं। मुझे लगता है कि मैं विकास कर रहा हूं। "

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

विशेषज्ञ प्रोग्रामर, नियमों को समझता है, लेकिन उनके संदर्भ भी। यह अंततः उन्हें नए विचारों और कार्यान्वयन के साथ आता है, एक विशेषज्ञ प्रोग्रामर का निशान। प्रोग्रामिंग आखिरकार एक कला है।

Comments

एक शिल्प जितना कला नहीं।

— थोरबजोरन रावन एंडरसन

मुझे ईमानदार होना सबसे ज्यादा पसंद है। मैं ऐसे कई डेवलपर्स को जानता हूं जो सुपर हार्ड और फास्ट नियमों में विश्वास करते हैं और उन नियमों की बड़ी तस्वीर नहीं देखते हैं कि वे नियम क्यों बनाए गए थे और उन मामलों में टूटे हुए हैं

— लांस ब्रायंट

Answer 9

अचानक से, एक अच्छा प्रोग्रामर का कोड पढ़ा और समझा जा सकता है।

मेरी राय में, एक अच्छा प्रोग्रामर का कोड भाषा-अज्ञेय है ; अच्छी तरह से लिखे गए कोड को कम से कम समय में कम से कम सोच के साथ पढ़ा और समझा जा सकता है, भले ही उपयोग की जाने वाली प्रोग्रामिंग भाषा की परवाह किए बिना। क्या कोड जावा, पायथन, सी ++ या हास्केल में है, अच्छी तरह से लिखा कोड उन लोगों द्वारा समझा जा सकता है जो उस विशेष भाषा में भी कार्यक्रम नहीं करते हैं।

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

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

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

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

Comments

मेरी राय में, एक अच्छा प्रोग्रामर का कोड भाषा-अज्ञेय +1

— nawfal

Answer 10

• पढ़ने में अासान
• लिखना आसान है
• संभालने में आसान

बाकी सब कुछ फिलिग्री है

Comments

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

— अल्लाव

@alpav: जो आप कहते हैं वह घटिया प्रोग्रामर के लिए बिल्कुल सही है, न कि इंटरमीडिएट और एक्सपर्ट प्रोग्रामर्स के लिए, जो जानते हैं कि एक साल में उन्हें अपना एक कोड बनाए रखना होगा, जिसमें उनकी कोई मेमोरी न हो, इसलिए वे चाहते हैं कि यह आसानी से पढ़ें और आसान हो जाए बनाए रखें। उन्हें प्राप्त किया जा सकता है और मैंने इसे 30 वर्षों तक बार-बार किया है, आप पूरी तरह से गलत हैं।

— क्लूक्स

अल्लाव: क्या आप एक उदाहरण दे सकते हैं कि दोनों कैसे परस्पर विरोधी हैं? वे मुझे पूरी तरह से संरेखित करते हैं: यदि आप इसे नहीं पढ़ सकते हैं तो आप कुछ कैसे बनाए रख सकते हैं?

— केन

Answer 11

अच्छे कोड को आसानी से समझा जाना चाहिए।
यह अच्छी तरह से टिप्पणी की जानी चाहिए।
कठिन भागों को और भी बेहतर टिप्पणी करनी चाहिए।

Comments

im यकीन नहीं है कि आप कह सकते हैं कि 'अच्छे कोड को आसानी से समझा जाना चाहिए' - कुछ कोड बहुत जटिल कार्य करते हैं, उन कार्यों को स्वयं आसानी से नहीं समझा जाता है, इसलिए यह तुरंत उस कोड का पालन नहीं करता है जिसे आप समझ नहीं सकते हैं बुरा कोड है - यह महान हो सकता है एक जटिल अवधारणा के माध्यम से काम करने वाला कोड।

— मांस

क्या जटिल, अच्छे कोड को चतुर कोड माना जाएगा?

— केविन्दुब

Answer 12

अच्छा कोड पठनीय है। आपको यह समझने में कोई परेशानी नहीं होगी कि एक अच्छे पेशेवर प्रोग्रामर द्वारा लिखे गए कोड के माध्यम से पहली बार पढ़ा जाने वाला कोड क्या कर रहा है।

Comments

दुर्भाग्य से "पठनीय" एक व्यक्तिपरक चीज है।

— ग्वेंथेन

Answer 13

बल्कि फिर हर किसी के महान सुझावों को दोहराएं, मैं इसके बजाय सुझाव दूंगा कि आप पुस्तक पढ़ें स्टीव मैककोनेल द्वारा कोड पूरा

मूलतः यह एक ऐसी पुस्तक है जो कार्यक्षमता और शैली दोनों के लिए प्रोग्रामिंग सर्वोत्तम प्रथाओं से भरी है।

Answer 14

[विशुद्ध रूप से व्यक्तिपरक उत्तर]
मेरे लिए, अच्छा कोड एक पेंटिंग की तरह, कला का एक रूप है। मैं आगे जा सकता हूं और कह सकता हूं कि यह वास्तव में एक ड्राइंग है जिसमें वर्ण, रंग, कोड का "रूप" या "संरचना" शामिल है, और यह सब इतना पठनीय / प्रदर्शन करने वाला है। पठनीयता, संरचना (यानी कॉलम, इंडेंटेशन, यहां तक ​​कि एक ही लंबाई के चर नाम!), रंग (वर्ग नाम, चर नाम, टिप्पणी, आदि) का संयोजन जो मुझे "सुंदर" चित्र के रूप में देखना पसंद है मुझे अपने कोड पर बहुत गर्व या बहुत घृणा करते हैं।

(जैसा कि पहले कहा गया था, बहुत व्यक्तिपरक जवाब। मेरी अंग्रेजी के लिए क्षमा करें।)

Answer 15

मैंने बॉब मार्टिन के "क्लीन कोड" की सिफारिश की।

"ब्यूटीफुल कोड" को कुछ साल पहले बहुत सराहा गया था।

मैककोनेल की कोई भी पुस्तक पढ़ने लायक है।

शायद "व्यावहारिक प्रोग्रामर" भी उपयोगी होगा।

%

Answer 16

बस मेरे 2 सेंट जोड़ना चाहते थे ... आपके कोड में टिप्पणियां - और आपका कोड ही, आमतौर पर - यह कहना चाहिए कि आपका कोड क्या करता है, अब यह कैसे करता है। एक बार आपके पास 'क्लाइंट' कोड की अवधारणा है, जो कोड है जो अन्य कोड को कॉल करता है (सबसे सरल उदाहरण कोड है जो एक विधि को कॉल करता है), आपको "क्लाइंट" के दृष्टिकोण से अपने कोड को समझने योग्य बनाने के लिए हमेशा सबसे अधिक चिंतित होना चाहिए। जैसे ही आपका कोड बढ़ता है, आप देखेंगे कि यह है ... उह, अच्छा है।

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

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

प्रोग्रामर के नजरिए और उपयोगकर्ता के नजरिए से, अच्छे कोड को भविष्य को ध्यान में रखते हुए लिखा जाता है।

Answer 17

यह फाउलर की पुस्तक "रिफैक्टिंग" में बहुत अच्छी तरह से उत्तर दिया गया है, यह पूरे पुस्तक में वर्णित सभी "महक" की अनुपस्थिति है।

Answer 18

मैंने 'प्रोफेशनल ASP.NET' नहीं देखा है, लेकिन मुझे आश्चर्य होगा कि यह ओके से बेहतर है। कुछ पुस्तकों के लिए इस प्रश्न को वास्तव में अच्छे कोड के साथ देखें । (यह निश्चित रूप से भिन्न होता है, लेकिन स्वीकृत उत्तर को हरा पाना मुश्किल है।)

Answer 19

ऐसा लगता है (होना चाहिए) एक सामान्य प्रश्न है। हाल ही में सुंदर कोड के बारे में एक एसीएम लेख है । पढ़ने / समझने में आसानी पर बहुत जोर दिया जाने लगता है। मैं इसे "डोमेन विशेषज्ञों द्वारा पढ़ने / समझने में आसान" के साथ क्वालिफ़ायर करता हूँ। वास्तव में अच्छे प्रोग्रामर किसी भी दी गई समस्याओं के लिए सबसे अच्छा एल्गोरिदम (बजाय भोले समझने के लिए O (n ^ 2) एल्गोरिदम) का उपयोग करते हैं, जिसका पालन करना कठिन हो सकता है, अगर आप एल्गोरिथ्म से परिचित नहीं हैं, भले ही अच्छा हो प्रोग्रामर एल्गोरिथम का संदर्भ देता है।

अच्छे प्रोग्रामर सहित कोई भी सही नहीं है, लेकिन उनके कोड के लिए प्रयास करते हैं:

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

Answer 20

मैं चाचा बॉब के "क्लीन कोड" के लिए सिफारिश करता हूं। लेकिन आप http://www.amazon.com/Im कार्यान्वयन-Patterns-Addison-Wesley-Signature-Kent/dp/ 0321413091 पर एक नज़र डालने की इच्छा कर सकते हैं क्योंकि मुझे लगता है कि यह आपके विशिष्ट प्रश्न से थोड़ा बेहतर है। अच्छा कोड पृष्ठ से छलांग लगाना चाहिए और आपको यह बताना चाहिए कि यह क्या करता है / यह कैसे काम करता है।

Answer 21

जेफ एटवुड ने एक अच्छा लेख लिखा कि कैसे कोडर्स टाइपिस्ट हैं पहला संदर्भ: http://www.codinghorror.com/blog/archives//111188.html

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

संरचना

टिप्पणियाँ

क्षेत्र

मैं एक सॉफ्टवेयर इंजीनियर हूं, जिसका अर्थ है कि मेरी शिक्षा के दौरान मैं कई अलग-अलग भाषाओं में आया हूं, लेकिन मेरी प्रोग्रामिंग हमेशा "समान" महसूस करती है, जैसा कि मेरा लेखन fekberg.wordpress.com पर करता है, मेरे पास टाइपिंग के लिए एक "विशेष" तरीका है।

अब विभिन्न अनुप्रयोगों और विभिन्न भाषाओं में, जैसे कि जावा, सी #, असेंबलर, सी ++, सी आई प्रोग्रामिंग करना मुझे पसंद है जो मुझे लिखना पसंद है।

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

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

इसके बारे में सोचें। यह भी पढ़ें कि मेरा पेपर Communication issues when adapting outsourcingकिस पर लिखा है , कितना बुरा है, कितना बुरा कोड संघर्ष कर सकता है, जैसा आप चाहें एंटर एंटर करें: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Answer 22

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

Answer 23

मेरे लिए महान कोड कुछ ऐसा है जो अभी तक परिष्कृत समझ के लिए सरल है। जिन चीजों से आप चलते हैं, "वाह, ज़ाहिर है, मैंने ऐसा क्यों नहीं सोचा?"। वास्तव में अच्छा कोड समझना मुश्किल नहीं है, यह बस सीधे-सीधे तरीके से समस्या को हल करता है (या एक पुनरावर्ती तरीका है, अगर यह और भी सरल है)।

Answer 24

अच्छा कोड वह है जहां आप जानते हैं कि नाम से विधि क्या करती है। खराब कोड वह जगह है जहां आपको नाम की समझ बनाने के लिए कोड को क्या करना है, इस पर काम करना होगा।

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

अच्छे कोड में चीजों का नाम इस तरह से रखा गया है ताकि तुच्छ टिप्पणियों को अनावश्यक बनाया जा सके।

अच्छा कोड छोटा हो जाता है।

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

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

Answer 25

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

जब एक प्रोग्रामर के पास उस मानसिकता होती है, तो अन्य सभी सामान अच्छी तरह से गिर जाते हैं।

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

Answer 26

(मैं का उपयोग करें "वह" नीचे क्योंकि वह व्यक्ति है कि मैं है की ख्वाहिश हो सकता है, कभी कभी सफलता के साथ)।

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

जैसे, उसका कोड निम्न है:

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

दूसरी ओर, मेरा मानना ​​है कि अच्छे प्रोग्रामर को ये काम कभी नहीं करने चाहिए:

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

Comments

@ की हो, हो, तुम्हारी बुद्धि ने मुझे अंधा कर दिया है, सर। अब विंग गॉगल्स दान करें: 8-पी

— बॉब क्रॉस

Answer 27

1. यह काम करता हैं
2. इसमें यूनिट परीक्षण हैं जो साबित करते हैं कि यह काम करता है

बाकी है आइसिंग ...

Answer 28

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

Answer 29

विडंबना यह है कि बेहतर प्रोग्रामर कम अपरिहार्य वह / वह हो जाता है क्योंकि कोड का उत्पादन बेहतर किसी के द्वारा पोषणीय (के रूप में Eran गैल्पेरिन द्वारा एक आम सहमति द्वारा कहा गया है)।

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

Answer 30

मेरे पास एक अच्छा उदाहरण है:

GWT (google web takenit) सोर्स कोड पढ़ें, आप देखेंगे कि हर मूर्ख इसे समझता है (कुछ अंग्रेजी किताबें इस कोड की तुलना में पढ़ने में कठिन हैं)।