क्या आप वास्तव में 'क्लीन कोड' लिखते हैं? [बन्द है]

54

मैंने कुछ प्रोग्रामर्स को बार-बार अपने कोड को 'अच्छा काम' करने के लिए ही नहीं, बल्कि इसे 'अच्छा' बनाने के लिए भी देखा है।

IMO, 'क्लीन कोड' वास्तव में एक प्रशंसा है जो यह दर्शाता है कि आपका कोड सुरुचिपूर्ण, पूरी तरह से समझने योग्य और बनाए रखने योग्य है। और यह अंतर तब सामने आता है जब आपको सौंदर्य की दृष्टि से आकर्षक कोड बनाम कोड के बीच चयन करना होता है जो देखने में तनावपूर्ण होता है।

तो, आप में से कितने वास्तव में 'क्लीन कोड' लिखते हैं? क्या यह एक अच्छा अभ्यास है? इसके अन्य लाभ या कमियां क्या हैं?

productivity

— ykombinator
स्रोत

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

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

52

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

मुझे जोएल स्पोलस्की की ब्लॉग पोस्ट: द डक्ट टेप प्रोग्रामर की याद दिलाई गई है ।

वह काम पर कोडर्स से उद्धरण :

दिन के अंत में, f ***** g चीज को शिप करें! अपने कोड को फिर से लिखना और इसे क्लीनर बनाना और तीसरी बार यह वास्तव में बहुत सुंदर होगा। लेकिन यह बात नहीं है - आप यहाँ कोड लिखने के लिए नहीं हैं; आप उत्पादों को शिप करने के लिए यहां हैं। - जेमी ज़विंस्की

मुझे रॉबर्ट मार्टिन की ब्लॉग प्रतिक्रिया भी याद आ रही है :

इसलिए। होशियार बनो। साफ रहें। साधारण रहो। समुंद्री जहाज! और डक्ट टेप का एक छोटा रोल तैयार रखें, और इसे इस्तेमाल करने से डरें नहीं। - चाचा बॉब

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

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

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

— स्पॉन्ज
स्रोत

45

जब तक आपका तकनीकी ऋण ( en.wikipedia.org/wiki/Technical_debt ) आपको "तकनीकी दिवालिया" नहीं कर सकता है (नई सुविधाएँ देने में असमर्थ है, एक भाग को ठीक करने पर दूसरा टूट जाता है, आदि ...), और यह कि आप नज़र रखते हैं इस पर, मैं सहमत हूं।

— Matthieu

3

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

— spong

40

"बस कमबख्त चीज को अभी शिप करें" के साथ समस्या यह है कि प्रबंधन बाद में रिफैक्टरिंग के लिए आपके कारणों को नहीं खरीदेगा, लेकिन यदि आप अदृश्य रूप से इसे करते हैं, तो यह सब अच्छा होगा।

— जॉब

5

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

— स्टीव चामिलार्ड 13

3

"आप इसे बाद में रिफ्लेक्टर कर सकते हैं" [उद्धरण वांछित]

— कार्ल लेथ

39

आपको यह सुनिश्चित करना होगा कि आपका कोड बहुत पठनीय, साफ और सुगम हो। यही सभी प्रोग्रामर को करना चाहिए ।

लेकिन आप इस बारे में बात कर रहे हैं over styling(जैसे उस शब्द को उस लड़की-संहिता से बेहतर ) जो अपने लेखक के अहंकार के अलावा कुछ नहीं करता।

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

यह तो ज्यादा है।

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

— रेव्स , 4 उपयोगकर्ता 81% user2567
स्रोत

13

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

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

14

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

— क्रैज

6

+1, मैंने पिछले दिनों कुछ पूरी तरह से स्टाइल वाले SPDEHETTI CODE देखे हैं।

— जस

23

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

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

3

@sunpech: इसे साफ लिखें, और इसे साफ रखना बहुत आसान है।

— डेविड थॉर्नले

24

मैं इस प्रश्न पर स्वीकृत उत्तर से असहमत हूं।

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

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

मुझे पता है कि इस बारे में एक आँकड़ा तैर रहा है, लेकिन कई परियोजनाओं के दौरान मेरे अनुभव में, कोड की प्रत्येक पंक्ति को विस्तार और रखरखाव के दौरान 5-20 बार पढ़ा जाता है।

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

— बेंजामिन वूटन
स्रोत

2

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

— jwenting

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

— साइमन व्हाइटहेड

1

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

— Jdahern

21

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

सॉफ्टवेयर के एक टुकड़े के लिए यह अलग क्यों होना चाहिए?

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

प्रश्न का उत्तर देते हुए "क्या आप वास्तव में 'क्लीन कोड' लिखते हैं?" -- अरे हां।!

— Sifar
स्रोत

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

— K.Steff

18

यदि 'क्लीन कोड' से आपका मतलब है कि मैं यह सुनिश्चित करने के लिए अपने रास्ते से हट जाऊंगा कि कोड जितना संभव हो उतना स्पष्ट है?

धत्त हां।

क्लीनर, कोड को साफ करता है, इसे बनाए रखना आसान है, और इस तरह से लंबे समय में आपका समय बचता है। घमंड के रूप में साफ कोड को मत देखो; इसे भविष्य के प्रयास और समय की बचत में निवेश के रूप में देखें।

— ग्रैंडमास्टरबी
स्रोत

15

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

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

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

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

— Satanicpuppy
स्रोत

माना। ज्यादातर लोग पहली बार जहाज को छोड़ने / जारी करने के लिए स्वच्छ कोड लिखने नहीं जा रहे हैं। काम करने के लिए डक्ट टेप शामिल है।

— स्पंज

2

डक्ट टेप के साथ पर्याप्त! स्पोलस्की भगवान नहीं है। वह अपनी पैंट को उस समय एक पैर पर रखता है जैसे हम करते हैं!

— जॉब

5

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

— पीटरऑलेनवेब

1

@ गैपर: और दो दशकों में, मैंने कभी ऐसा स्थान नहीं देखा, जहाँ कोड का हर टुकड़ा साफ था। मैंने शायद ही कभी ऐसी जगह देखी हो जहाँ आधा था। तुम कहा जॉब करती हो? नासा?

— शैतानिकपुपी

2

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

— पीटरऑलेनवेब

7

मुझे नहीं लगता कि मुझे "गर्ल कोड" शब्द पसंद है, लेकिन स्वच्छ कोड = रखरखाव योग्य कोड। कुछ भी कम होना अव्यवसायिक है।

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

बहुत समय यह मेरे पास है ... कई महीनों बाद ... जब मुझे याद नहीं है कि यह कैसे काम करता है ... और मेरे पास बदलाव करने के लिए भी कम समय है।

— हीथ लिली
स्रोत

5

मैं बॉब मार्टिन अर्थ (जैसे OO डिजाइन) में "क्लीन कोड" लिखने की कोशिश करता हूं। नहीं है महान साफ कोड लिखने में मूल्य। यह बहुत अधिक बनाए रखने योग्य है।

फिर मैंने ReSharper को मेरे लिए "सुंदर कोड" (जैसे संरेखण, लाइन ब्रेक आदि) बनाने दिया। नहीं है अच्छा सुंदर कोड लिखने में मूल्य। लेकिन कम रिटर्न दे रहे हैं। पढ़ने में आसानी के कारण कुछ पूर्वधारणा इसे थोड़ा अधिक बनाए रखती है।

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

अगर मेरे पास ReSharper नहीं होता, तो मेरे पास अभी भी साफ कोड होता, लेकिन यह बहुत सुंदर नहीं होता।

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

— dss539
स्रोत

4

ऐसा लगता है कि कोई भी आपकी कंपनी के सर्वोत्तम हित में इस मुद्दे को नहीं उठाता है ?

अक्सर, यदि हमेशा नहीं होता है, तो प्रोग्रामर सिर्फ कर्मचारी होते हैं, और जबकि प्रबंधन के फैसले हमें निराश कर सकते हैं, हमारे पास अक्सर सभी डेटा नहीं होते हैं।

उदाहरण के लिए, मान लें कि कंपनी को एक क्लॉज़ के साथ अनुबंधित किया गया है, यदि सॉफ़्टवेयर समय पर तैयार नहीं होता है, तो आपको भुगतान नहीं किया जाएगा (यह सिर्फ हमारे लिए हुआ है, हालांकि मुझे लगता है कि हमें भुगतान सभी के बाद मिला)। हाँ, साफ कोड महत्वपूर्ण है, लेकिन अधिक महत्वपूर्ण भुगतान दिवस तक काम करने वाले कोड का होना है!

एक और उदाहरण - कंपनी खराब वित्तीय स्थिति में है और कुछ पैसे जुटाने की जरूरत है। लगता है जो गुणवत्ता के बारे में परवाह है? आप इसे बाद में ठीक कर सकते हैं, यदि आपको करना है, तो बस इसे शिप करें!

एक तर्क हो सकता है "मुझे क्यों बेचना चाहिए और भद्दा कोड लिखना चाहिए?"। ठीक है, आपकी कंपनी को आपको हर महीने एक अच्छा चेक क्यों देना चाहिए? विकल्प, मेरे दोस्त। यदि आप आदर्शवाद के बाद हैं, तो फ्री सॉफ्टवेयर फाउंडेशन का प्रयास करें ; मैंने सुना है वे कुछ बहुत अच्छा सामान कर रहे हैं (मेरा मतलब है कि यह एक है, और मैं FSF और OSS का सम्मान करता हूं)।

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

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

तो कभी-कभी, अहंकार को एक तरफ, हमें बस इसे काम में लाना चाहिए। ध्यान दें कि मैं आदत के रूप में खराब कोड लिखने की सलाह नहीं देता; मैं सिर्फ इशारा कर रहा हूं कि यह जरूरी हो सकता है। पूर्णता में वह समय लगता है जो आपकी कंपनी के पास नहीं हो सकता है। इसलिए यदि आपका नियोक्ता मन नहीं करता है, तो क्राफ्ट सॉफ्टवेयर, लेकिन अगर आपको जरूरत है, तो बस वर्किंग कोड लिखें, कभी भी 'सफाई' पर ध्यान न दें। यह सिर्फ एक 'एक आकार सभी फिट बैठता है' का जवाब नहीं है - आपको प्राथमिकता देनी चाहिए।

— K.Steff
स्रोत

3

मुझे यकीन नहीं है कि "अच्छी दिख रही है" और "सुरुचिपूर्ण, पूरी तरह से समझने योग्य और बनाए रखने योग्य" समकक्ष है।

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

समय में परिणामी लागत को छोड़कर मुझे कोई कमियां नहीं दिखतीं।

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

— back2dos
स्रोत

2

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

— jsternberg

3

किसी भी चीज की अति कभी भी अच्छी नहीं होती।

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

इसलिए कोड में साफ-सफाई का एक निश्चित स्तर बनाए रखना आपके साथी डेवलपर्स से ज्यादा फायदेमंद है। उस पर बहुत अधिक समय खर्च न करें (~ 5% का उल्लेख किया गया है)। मैन्युअल कार्यों को स्वचालित करने के लिए अपने शिल्प के उपकरणों का उपयोग करना सीखें (इस मामले में कोड स्वरूपण)। आप जो करते हैं उसके लिए जिम्मेदारी लें और हमेशा वही करें जो आपको लगता है कि आपकी कंपनी / ग्राहकों / उपयोगकर्ताओं के लिए सबसे अधिक फायदेमंद है।

— प्रति नाल्ट
स्रोत

3

यह बॉब मार्टिन द्वारा स्वच्छ संहिता का एक उद्धरण है:

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

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

— ट्यूलेंस कोर्डोवा
स्रोत

2

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

— chiurox
स्रोत

2

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

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

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

ठीक है ... यह उद्देश्य-सी विधियों के साथ बदतर है, और बहुत सारे और बहुत से नेस्टेड हैं यदि कथन, और लाइनें 80 से अधिक वर्णों की हैं। लेकिन यह अभी भी मुझे गुस्सा दिलाता है :)

— vedosity
स्रोत

2

मैं कोड को साफ करने के लिए बड़ी लंबाई में जाता हूं। मुझे लगता है कि इससे कीड़े बाहर खड़े होने में बहुत मदद करते हैं।

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

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

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

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

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

यह कोड का एक टुकड़ा है जो मेरी कोडिंग शैली को प्रदर्शित करता है।

— रेव्स , 2 उपयोगकर्ता 89% user20416
स्रोत

1

बस "घमंड कोड" से बचें। वहाँ बहुत सारे डेवलपर्स हैं जो कि विशुद्ध रूप से घमंड से बाहर चीजें करते हैं (या एक ओसीडी के कारण) और कुछ नहीं। मेरी पैंटी वाकई उन लोगों के साथ जुड़ जाती है।

— ElGringoGrande
स्रोत

विंग या (बदतर) बॉक्स टिप्पणियों की तरह, कहते हैं?

— डेविड थॉर्नले

1

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

मैंने अपने सीमित अनुभवों में जो पाया है वह यह है कि जब लोग 'क्लीन-कोड' के बारे में शिकायत करते हैं, तो कुरूपता आमतौर पर कोडिंग कन्वेंशन के बजाय एक भयानक समाधान का परिणाम है।

— कुर्तियां
स्रोत

1

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

स्वच्छ कोड अच्छा है, लेकिन बाकी सब की तरह, इसे बस पर्याप्त रूप से साफ करने की आवश्यकता है। कोड 4 रिक्त स्थान की 5 पंक्तियों और एक पंक्ति 5 स्थानों को पढ़ने की कठिनाई को नहीं बढ़ाता है।

— JeffO
स्रोत

1

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

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

लेकिन यह भी, यह इस बात पर निर्भर करता है कि 'क्लीन-कोड' से आपका क्या मतलब है।

— user7007
स्रोत

0

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

— user281377
स्रोत

0

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

int foo    = 1;
int bar    = 2;
int foobar = 3;

से पढ़ना आसान है

int foo = 1;
int bar = 2;
int foobar = 3;

जिसका अर्थ है कि जब आप बाद में डिबगिंग कर रहे हों, तो इसे रोकना आसान है।

इसके अलावा, PHP में आपको किसी भी प्रकार के यादृच्छिक कोड ब्लॉक की अनुमति है। मैं इनका उपयोग तार्किक कार्यों को पूरा करने के लिए करता हूँ:

// do x
{
    // ...
}

// do y
{
    // ...
}

यह प्रासंगिक कोड के लिए स्पष्ट परिभाषा जोड़ता है।

संपादित करें : एक अतिरिक्त बोनस के रूप में, if (false)यदि आप अस्थायी रूप से इसे छोड़ना चाहते हैं , तो उन तार्किक कोड ब्लॉकों में से एक को पूर्ववर्ती करना आसान है ।

— Craige
स्रोत

11

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

— riwalk

1

@ stargazer712: परिभाषित नामस्थानों की कमी के कारण मुझे php के कार्यों से नफरत है। अनिवार्य रूप से, कोई व्यक्ति कोड पढ़ता है, उनके पास शीर्ष पर एक "शामिल" है, जिसमें स्वयं 5 अन्य चीजें शामिल हैं, जिनमें से प्रत्येक में 4 और शामिल हैं, और फिर मुझे फ़ंक्शन की परिभाषा खोजने के लिए पूरे कोड आधार पर एक खोज करनी होगी। अधिक निराश।

— शैतानिकपुप्पी

अक्सर यह कोड होता है जो फ़ंक्शन घोषणा को वारंट नहीं करता है। जैसे। पुन: उपयोग, गणना / संबंधित स्थानीय-दायरे चर, आदि की स्थापना के लिए कोई संभावना

— Craige

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

— riwalk

-2

मैं सिर्फ कंपनी के मानकों का पालन करते हुए अपना कोड लिखता हूं। अगर मैं इसे "पहले से बता दिया" चाहता हूं, तो मैं इसे एक कोड ब्यूटिफायर के माध्यम से चला सकता हूं।

— Muad'Dib
स्रोत

2

सिवाय इसके कि जो आम तौर पर होता है, वह कोई और होता है, जिसे वह एक ब्यूटीफायर के जरिए चलाने की कोशिश करता है।

— रिवलॉक

@ Stargazer712 जो वास्तव में क्यों मैं कंपनी के मानकों का पालन करने से ज्यादा परेशान नहीं करता है

— Muad'Dib

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

— riwalk

@ Stargazer712 समस्या है, "कंपनी मानकों" को छोड़कर बाकी सब पूरी तरह से स्वाद का मामला है, जो व्यक्तिपरक है। उदाहरण के लिए, मैं उन जगहों पर जगह बनाना पसंद करता हूं जहां मेरे सहकर्मी सकारात्मक रूप से उनसे नफरत करते हैं। मुझे यह अच्छा लगता है, और मैं जहाँ तक जाता हूँ।

— मुदितिब

1

"ब्यूटिफायर" के साथ सावधान रहें, क्योंकि वे बड़े समय में विलय करने में गड़बड़ी कर सकते हैं (मुझे पहला हाथ अनुभव मिला है :))।

— जूहा अन्टिनन