रॉबर्ट मार्टिन द्वारा क्लीन कोड। सार। स्पष्ट और सुंदर कोड कैसे लिखें?

मैंने पुस्तक का एक संग्रह लिखने का फैसला किया, जिसे हर कोई जानता है, और लेखक इसे "स्कूल ऑफ प्योर कोड टीचर्स" कहते हैं। मार्टिन की निगाहें कह रही हैं:

“मैं तुम्हारे माध्यम से सही देखता हूँ। क्या आप फिर से स्वच्छ कोड के सिद्धांतों का पालन नहीं करते हैं? "

अध्याय 1. स्वच्छ संहिता

कुछ शब्दों में यह सबसे स्वच्छ मार्टिन संस्करण कोड क्या है? यह दोहराव के बिना कोड है, न्यूनतम संख्या में संस्थाओं के साथ, पढ़ने में आसान, सरल। एक आदर्श वाक्य के रूप में, कोई भी चुन सकता है: "स्पष्टता सभी से ऊपर है!"।

अध्याय 2. सार्थक नाम

नामों को प्रोग्रामर के इरादों को व्यक्त करना चाहिए

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

एक अच्छा चर नाम का एक उदाहरण: daysSinceCreation;
उद्देश्य: गैर स्पष्टता को हटा दें।

गलत सूचना से बचें

अभिप्राय के अलावा अन्य छिपे हुए अर्थ वाले शब्दों का प्रयोग न करें। नामों में सूक्ष्म अंतर से सावधान रहें। उदाहरण के लिए, XYZControllerForEfficientHandlingOfStrings और XYZControllerForEfficientStorageOfStrings।

गलत रूप से नाम के गलत रूप से भयावह उदाहरण लोअरकेस "एल" का उपयोग करते समय पाए जाते हैं और राजधानी "ओ" चर नामों में, विशेष रूप से संयोजनों में। स्वाभाविक रूप से, इस तथ्य के कारण समस्याएं पैदा होती हैं कि ये पत्र क्रमशः "1" और "0" स्थिरांक से भिन्न नहीं होते हैं।

सार्थक अंतर का उपयोग करें

यदि नाम अलग हैं, तो उन्हें विभिन्न अवधारणाओं को इंगित करना चाहिए।

फ़ॉर्म की "संख्या श्रृंखला" (a1, a2, ... aN) सचेत नामकरण के विपरीत हैं। वे जानकारी नहीं देते हैं और लेखक के इरादों का अंदाजा नहीं लगाते हैं।

असंसदीय शब्द बेमानी हैं। शब्द चर को चर नामों में कभी नहीं दिखाना चाहिए। शब्द तालिका को तालिका नामों में कभी नहीं दिखाना चाहिए। NameString नाम से बेहतर क्यों है? क्या एक नाम, एक वास्तविक संख्या कह सकता है?

स्पेलिंग नामों का उपयोग करें: जेनटाइम्ड की तुलना में जेनटाइमेस्टैम्प बहुत बेहतर है।

खोज योग्य नाम चुनें

एकल-अक्षर नामों का उपयोग केवल लघु विधियों में स्थानीय चर के लिए किया जा सकता है।

नाम कोडिंग योजनाओं से बचें

एक नियम के रूप में, कोडित नाम खराब रूप से स्पष्ट हैं और उनमें टाइपो बनाना आसान है।

इंटरफेस और कार्यान्वयन

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

वर्ग के नाम

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

विधि नाम

विधि के नाम क्रिया या मौखिक वाक्यांश हैं: पोस्टपेमेंट, डिलीट, सेव, आदि। पढ़ें / लिखें विधियां और विधेय मूल्य और उपसर्ग से प्राप्त होते हैं, सेट होते हैं और javabean मानक के अनुसार होते हैं।

दण्ड से बचना

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

सार्थक संदर्भ जोड़ें।

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

अस्पष्ट संदर्भ के साथ चर:

private void printGuessStatistics(char candidate, int count) { String number; String verb; String pluralModifier; if (count == 0) { number = "no"; verb = "are"; pluralModifier = "s"; } else if (count == 1) { number = ~_~quot quot~_~; verb = "is"; pluralModifier = ""; } else { number = Integer.toString(count); verb = "are"; pluralModifier = "s"; } String guessMessage = String.format( "There %s %s %s%s", verb, number, candidate, pluralModifier ); print(guessMessage); } 

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

संदर्भ के साथ चर:

 public class GuessStatisticsMessage { private String number; private String verb; private String pluralModifier; public String make(char candidate, int count) { createPluralDependentMessageParts(count); return String.format( "There %s %s %s%s", verb, number, candidate, pluralModifier ); } private void createPluralDependentMessageParts(int count) { if (count == 0) { thereAreNoLetters(); } else if (count == 1) { thereIsOneLetter(); } else { thereAreManyLetters(count); } } private void thereAreManyLetters(int count) { number = Integer.toString(count); verb = "are"; pluralModifier = "s"; } private void thereIsOneLetter() { number = ~_~quot quot~_~; verb = "is"; pluralModifier = ""; } private void thereAreNoLetters() { number = "no"; verb = "are"; pluralModifier = "s"; } } 

अनावश्यक संदर्भ न जोड़ें

छोटे नाम आमतौर पर लंबे नामों से बेहतर होते हैं, यदि कोड रीडर में केवल उनका अर्थ स्पष्ट हो। नाम में आवश्यकता से अधिक संदर्भ शामिल न करें।

अध्याय 3. कार्य

सघनता!

पहला नियम: फ़ंक्शंस कॉम्पैक्ट होना चाहिए।
दूसरा नियम: फ़ंक्शन और भी अधिक कॉम्पैक्ट होना चाहिए।

मेरे व्यावहारिक अनुभव ने मुझे (कई परीक्षण और त्रुटि की कीमत पर) सिखाया है कि फ़ंक्शन बहुत छोटा होना चाहिए। यह वांछनीय है कि फ़ंक्शन की लंबाई 20 लाइनों से अधिक नहीं है।

एक ऑपरेशन का नियम

एक फ़ंक्शन को केवल एक ऑपरेशन करना होगा। उसे अच्छा प्रदर्शन करना होगा। और उसे कुछ और नहीं करना चाहिए। यदि कोई फ़ंक्शन केवल उन कार्यों को करता है जो फ़ंक्शन के घोषित नाम के तहत समान स्तर पर हैं, तो यह फ़ंक्शन एक ऑपरेशन करता है।

समारोह अनुभाग

एक फ़ंक्शन जो केवल एक ऑपरेशन करता है, उसे सार्थक रूप से अनुभागों में विभाजित नहीं किया जा सकता है।

समारोह के प्रति अमूर्त का एक स्तर

यह सुनिश्चित करने के लिए कि फ़ंक्शन "केवल एक ऑपरेशन" करता है, यह सत्यापित करना आवश्यक है कि फ़ंक्शन के सभी कमांड्स अमूर्तता के समान स्तर पर हैं।

किसी फ़ंक्शन के भीतर अमूर्तता का सम्मिश्रण स्तर हमेशा भ्रम पैदा करता है।

कोड को ऊपर से नीचे तक पढ़ना: डाउनग्रेड नियम

कोड को कहानी की तरह पढ़ना चाहिए - ऊपर से नीचे तक।

प्रत्येक फ़ंक्शन को अमूर्त के अगले स्तर के कार्यों का पालन करना चाहिए। यह आपको फ़ंक्शन की सूची को पढ़ते समय कोड को क्रमिक रूप से अमूर्त के स्तर से नीचे जाने की अनुमति देता है। मैं इस दृष्टिकोण को "डाउनग्रेड नियम" कहता हूं।

आदेशों को स्विच करें

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

उदाहरण केवल एक ऑपरेशन दिखाता है, जो कर्मचारी के प्रकार पर निर्भर करता है।

 public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } 

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

चौथा, यह ओपन बंद सिद्धांत का उल्लंघन करता है, क्योंकि हर बार नए प्रकार जोड़े जाने पर फ़ंक्शन कोड को बदलना होगा।

लेकिन शायद सबसे गंभीर दोष यह है कि कार्यक्रम में समान संरचना के साथ अन्य कार्यों की असीमित संख्या हो सकती है, उदाहरण के लिए:

isPayday (कर्मचारी ई, तिथि तिथि)

या

सुपुर्दगी (कर्मचारी ई, पैसा देना)

और इसी तरह।

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

 public abstract class Employee { public abstract boolean isPayday(); public abstract Money calculatePay(); public abstract void deliverPay(Money pay); } ----------------- public interface EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType; } ----------------- public class EmployeeFactoryImpl implements EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType { switch (r.type) { case COMMISSIONED: return new CommissionedEmployee(r) ; case HOURLY: return new HourlyEmployee(r); case SALARIED: return new SalariedEmploye(r); default: throw new InvalidEmployeeType(r.type); } } } 

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

सार्थक नामों का उपयोग करें

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

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

कार्य तर्क

आदर्श मामले में, फ़ंक्शन तर्कों की संख्या शून्य है। निम्नलिखित एक तर्क (एकात्मक) और दो तर्कों (बाइनरी) के साथ कार्य करते हैं। जब भी संभव हो तीन तर्कों (टर्नरी) वाले कार्यों से बचा जाना चाहिए।

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

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

झंडे तर्क

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

बाइनरी फ़ंक्शन

एक फ़ंक्शन के साथ दो तर्कों को समझना एक कठिन कार्य की तुलना में अधिक कठिन है। बेशक, कुछ स्थितियों में, एक दो-तर्क रूप उपयुक्त है। उदाहरण के लिए, कॉलिंग पॉइंट p = नया पॉइंट (0,0); बिल्कुल उचित है। हालांकि, हमारे मामले में दो तर्क एक ही मूल्य के घटक हैं।

तर्क के रूप में वस्तुएँ

यदि किसी फ़ंक्शन को दो या तीन से अधिक तर्क प्राप्त होने चाहिए, तो यह अत्यधिक संभावना है कि इनमें से कुछ तर्क अलग वर्ग में पैक किए जाने चाहिए। निम्नलिखित दो घोषणाओं पर विचार करें:

 Circle makeCircle(double x, double y, double radius); Circle makeCircle(Point center, double radius); 

यदि चर को एक पूरे के रूप में एक साथ स्थानांतरित किया जाता है (जैसे x और y चर इस उदाहरण में), तो, सबसे अधिक संभावना है, एक साथ वे एक अवधारणा बनाते हैं जो अपने स्वयं के नाम के हकदार हैं।

क्रिया और खोजशब्द

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

पाठक समझता है कि "नाम" क्या है, यह कहीं नहीं लिखा है। इससे भी बेहतर राइटफिल्ड (नाम) रिकॉर्ड है, जो रिपोर्ट करता है कि "नाम" कुछ संरचना के "फ़ील्ड" को लिखा गया है।

अंतिम प्रविष्टि एक फ़ंक्शन नाम में कीवर्ड का उपयोग करने का एक उदाहरण है। इस रूप में, तर्क नाम फ़ंक्शन नाम में एन्कोड किए गए हैं। उदाहरण के लिए, assertEquals को assertExpectedEqualsActual (अपेक्षित, वास्तविक) के रूप में लिखा जा सकता है। यह काफी हद तक तर्कों के क्रम को याद रखने की समस्या को हल करता है।

आदेशों और अनुरोधों का पृथक्करण

एक फ़ंक्शन को कुछ करना चाहिए या कुछ प्रश्न का उत्तर देना चाहिए, लेकिन एक साथ नहीं। या तो फ़ंक्शन ऑब्जेक्ट की स्थिति को बदलता है, या इस ऑब्जेक्ट के बारे में जानकारी देता है। दो ऑपरेशनों को मिलाकर अक्सर भ्रम पैदा होता है।

ब्लॉक को पकड़ने / पकड़ने का प्रयास करें

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

एक ऑपरेशन के रूप में हैंडलिंग में त्रुटि

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

यह अध्याय 3 का समापन करता है।