स्वच्छ जावास्क्रिप्ट कोड लिखने के लिए दिशानिर्देश

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



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

कोड और डब्ल्यूटीएफ प्रश्न

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

जब खुद से किसी और के कोड के बारे में डब्ल्यूटीएफ सवाल पूछते हैं, तो प्रोग्रामर खुद से पूछते हैं कि यह क्या है (डब्ल्यूटीएफ वह है?), कोड के लेखक ने क्या करने की कोशिश की (डब्ल्यूटीएफ आपने यहां किया?), यह कोड में मौजूद या डब्ल्यूटीएफ क्यों है? इसके लिए;)

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


बाईं ओर अच्छा कोड है। सही करने के लिए बुरा है

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

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

1. सख्त समानता की जाँच

== बजाय === का उपयोग करने का प्रयास करें।

 //     == -       .     ,   ,   ,   -    . 0 == false // true 0 === false // false 2 == "2" // true 2 === "2" // false //  const value = "500"; if (value === 500) { console.log(value); //     } if (value === "500") { console.log(value); //    } 

2. चर

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

 let daysSLV = 10; let y = new Date().getFullYear(); let ok; if (user.age > 30) { ok = true; } 

अच्छा:

 const MAX_AGE = 30; let daysSinceLastVisit = 10; let currentYear = new Date().getFullYear(); ... const isUserOlderThanAllowed = user.age > MAX_AGE; 

जिन चर नामों की आवश्यकता नहीं है, उन्हें अतिरिक्त शब्द जोड़ने की आवश्यकता नहीं है।

खराब:

 let nameValue; let theProduct; 

अच्छा:

 let name; let product; 

आपको किसी ऐसे व्यक्ति को मजबूर नहीं करना चाहिए जो उस कोड को पढ़ता है जिसमें पर्यावरण को याद रखना है जिसमें चर घोषित किया गया है।

खराब:

 const users = ["John", "Marco", "Peter"]; users.forEach(u => { doSomething(); doSomethingElse(); // ... // ... // ... // ... //    ,    WTF- "   `u`?" register(u); }); 

अच्छा:

 const users = ["John", "Marco", "Peter"]; users.forEach(user => { doSomething(); doSomethingElse(); // ... // ... // ... // ... register(user); }); 

आपको उस संदर्भ के बारे में अनावश्यक जानकारी के साथ चर नामों की आपूर्ति करने की आवश्यकता नहीं है जिसमें वे उपयोग किए जाते हैं।

खराब:

 const user = { userName: "John", userSurname: "Doe", userAge: "28" }; ... user.userName; 

अच्छा:

 const user = { name: "John", surname: "Doe", age: "28" }; ... user.name; 

3. कार्य

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

खराब:

 function notif(user) { //  } 

अच्छा:

 function notifyUser(emailAddress) { //  } 

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

खराब:

 function getUsers(fields, fromDate, toDate) { //  } 

अच्छा:

 function getUsers({ fields, fromDate, toDate }) { //  } getUsers({ fields: ['name', 'surname', 'email'], fromDate: '2019-01-01', toDate: '2019-01-18' }) 

डिफ़ॉल्ट तर्क का उपयोग करें, उन्हें सशर्त निर्माणों पर वरीयता दें।

खराब:

 function createShape(type) { const shapeType = type || "cube"; // ... } 

अच्छा:

 function createShape(type = "cube") { // ... } 

एक फ़ंक्शन को एक समस्या को हल करना चाहिए। यह सुनिश्चित करने के लिए प्रयास करें कि एक फ़ंक्शन कई क्रियाएं नहीं करता है।

खराब:

 function notifyUsers(users) { users.forEach(user => {   const userRecord = database.lookup(user);   if (userRecord.isVerified()) {     notify(user);   } }); } 

अच्छा:

 function notifyVerifiedUsers(users) { users.filter(isUserVerified).forEach(notify); } function isUserVerified(user) { const userRecord = database.lookup(user); return userRecord.isVerified(); } 

डिफ़ॉल्ट रूप से ऑब्जेक्ट के गुण सेट करने के लिए Object.assign का उपयोग करें।

खराब:

 const shapeConfig = { type: "cube", width: 200, height: null }; function createShape(config) { config.type = config.type || "cube"; config.width = config.width || 250; config.height = config. height || 250; } createShape(shapeConfig); 

अच्छा:

 const shapeConfig = { type: "cube", width: 200 //   'height'   }; function createShape(config) { config = Object.assign(   {     type: "cube",     width: 250,     height: 250   },   config ); ... } createShape(shapeConfig); 

मापदंडों के रूप में झंडे का उपयोग न करें। उनके उपयोग का मतलब है कि फ़ंक्शन जितना कार्य करना चाहिए था उससे अधिक कार्य करता है।

खराब:

 function createFile(name, isPublic) { if (isPublic) {   fs.create(`./public/${name}`); } else {   fs.create(name); } } 

अच्छा:

 function createFile(name) { fs.create(name); } function createPublicFile(name) { createFile(`./public/${name}`); } 

वैश्विक दायरे को प्रदूषित न करें। यदि आपको किसी मौजूदा ऑब्जेक्ट का विस्तार करने की आवश्यकता है, तो मानक वस्तुओं के प्रोटोटाइप श्रृंखला में फ़ंक्शन बनाने के बजाय ES कक्षाओं और विरासत तंत्र का उपयोग करें।

खराब:

 Array.prototype.myFunc = function myFunc() { //  }; 

अच्छा:

 class SuperArray extends Array { myFunc() {   //  } } 

4. सशर्त निर्माण

बूलियन चरों का नाम न रखने का प्रयास करें ताकि उनके नाम में नकारात्मकता हो। वही ऐसे कार्यों के लिए जाता है जो बूलियन मान लौटाते हैं। सशर्त निर्माणों में ऐसी संस्थाओं का उपयोग करना कोड को पढ़ना मुश्किल बनाता है।

खराब:

 function isUserNotBlocked(user) { //  } if (!isUserNotBlocked(user)) { //  } 

अच्छा:

 function isUserBlocked(user) { //  } if (isUserBlocked(user)) { //  } 

सशर्त निर्माण के लिए संक्षिप्त रूप का उपयोग करें। शायद यह सिफारिश तुच्छ लग सकती है, लेकिन यह ध्यान देने योग्य है। इस दृष्टिकोण का उपयोग केवल तार्किक चर के लिए करें, और यदि आप सुनिश्चित हैं कि चर का मान undefined या null नहीं होगा।

खराब:

 if (isValid === true) { // - ... } if (isValid === false) { // - ... } 

अच्छा:

 if (isValid) { // - ... } if (!isValid) { // - ... } 

जहां भी संभव हो तार्किक निर्माण से बचें। इसके बजाय बहुरूपता और वंशानुक्रम का उपयोग करें।

खराब:

 class Car { // ... getMaximumSpeed() {   switch (this.type) {     case "Ford":       return this.someFactor() + this.anotherFactor();     case "Mazda":       return this.someFactor();     case "McLaren":       return this.someFactor() - this.anotherFactor();   } } } 

अच्छा:

 class Car { // ... } class Ford extends Car { // ... getMaximumSpeed() {   return this.someFactor() + this.anotherFactor(); } } class Mazda extends Car { // ... getMaximumSpeed() {   return this.someFactor(); } } class McLaren extends Car { // ... getMaximumSpeed() {   return this.someFactor() - this.anotherFactor(); } } 

5. ES कक्षाएं

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

खराब:

 const Person = function(name) { if (!(this instanceof Person)) {   throw new Error("Instantiate Person with `new` keyword"); } this.name = name; }; Person.prototype.sayHello = function sayHello() { /**/ }; const Student = function(name, school) { if (!(this instanceof Student)) {   throw new Error("Instantiate Student with `new` keyword"); } Person.call(this, name); this.school = school; }; Student.prototype = Object.create(Person.prototype); Student.prototype.constructor = Student; Student.prototype.printSchoolName = function printSchoolName() { /**/ }; 

अच्छा:

 class Person { constructor(name) {   this.name = name; } sayHello() {   /* ... */ } } class Student extends Person { constructor(name, school) {   super(name);   this.school = school; } printSchoolName() {   /* ... */ } } 

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

खराब:

 class Person { constructor(name) {   this.name = name; } setSurname(surname) {   this.surname = surname; } setAge(age) {   this.age = age; } save() {   console.log(this.name, this.surname, this.age); } } const person = new Person("John"); person.setSurname("Doe"); person.setAge(29); person.save(); 

अच्छा:

 class Person { constructor(name) {   this.name = name; } setSurname(surname) {   this.surname = surname;   //  this           return this; } setAge(age) {   this.age = age;   //  this           return this; } save() {   console.log(this.name, this.surname, this.age);   //  this           return this; } } const person = new Person("John")   .setSurname("Doe")   .setAge(29)   .save(); 

6. क्या न करना बेहतर है

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

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

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

यदि आप अनावश्यक कोड के खिलाफ लड़ाई को बंद कर देते हैं, तो कार्यक्रम निम्न आकृति में दिखाया गया है।


कभी-कभी मेरा कोड इस बालकनी की तरह दिखता है। मुझे नहीं पता कि वह किस कार्य को हल कर रहा है, लेकिन मैं उससे छुटकारा पाने से डरता हूं।

परिणाम

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

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

• एक साफ और स्केलेबल जावास्क्रिप्ट कोड लिखना: 12 युक्तियां।
• स्वच्छ और सुंदर कोड कैसे लिखें ।
• जावास्क्रिप्ट कोड के लिए 7 सिफारिशें
• BIF पैटर्न: सर्वर डेटा के साथ क्लीन-एंड कोड और सुविधाजनक कार्य ।
• जावास्क्रिप्ट गाइड भाग 2: कोड शैली और कार्यक्रम संरचना
• जावास्क्रिप्ट: कोड स्पष्टता का मार्ग।

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

प्रिय पाठकों! क्या आपने कभी किसी और के कोड को पढ़ते हुए डब्ल्यूटीएफ प्रश्न पूछे हैं?