يجب أن يكون الكود الخاص بنا واضحًا وسهل القراءة قدر الإمكان.
هذا هو في الواقع فن البرمجة – القيام بمهمة معقدة وبرمجتها بطريقة صحيحة ويمكن للبشر قراءتها. يساعد أسلوب التعليمات البرمجية الجيد بشكل كبير في ذلك.
فيما يلي ورقة الغش التي تحتوي على بعض القواعد المقترحة (انظر أدناه لمزيد من التفاصيل):
الآن دعونا نناقش القواعد وأسبابها بالتفصيل.
لا توجد قواعد "يجب عليك".
لا يوجد شيء محفور هنا. هذه هي تفضيلات الأسلوب، وليس العقائد الدينية.
في معظم مشاريع جافا سكريبت، تتم كتابة الأقواس المتعرجة بالنمط "المصري" مع قوس الافتتاح على نفس سطر الكلمة الرئيسية المقابلة - وليس على سطر جديد. يجب أيضًا أن تكون هناك مسافة قبل قوس الفتح، مثل هذا:
إذا (شرط) { // افعل هذا // ...وهذا // ...وهذا }
تعتبر البنية ذات السطر الواحد، مثل if (condition) doSomething()
، حالة حافة مهمة. هل يجب علينا استخدام الأقواس على الإطلاق؟
فيما يلي المتغيرات المشروحة حتى تتمكن من الحكم على سهولة قراءتها بنفسك:
؟ المبتدئين يفعلون ذلك في بعض الأحيان. سيء! ليست هناك حاجة للأقواس المتعرجة:
إذا (n < 0) {alert(`الطاقة ${n} غير مدعومة`);}
؟ تقسيم إلى سطر منفصل دون الأقواس. لا تفعل ذلك أبدًا، فمن السهل ارتكاب خطأ عند إضافة أسطر جديدة:
إذا (ن <0) تنبيه ("الطاقة ${n} غير مدعومة")؛
؟ سطر واحد بدون أقواس – مقبول إذا كان قصيراً:
إذا (n < 0) تنبيه ("الطاقة ${n} غير مدعومة")؛
؟ أفضل البديل:
إذا (ن <0) { تنبيه ("الطاقة ${n} غير مدعومة")؛ }
بالنسبة إلى التعليمات البرمجية المختصرة جدًا، يُسمح بسطر واحد، على سبيل المثال، if (cond) return null
. لكن كتلة التعليمات البرمجية (الإصدار الأخير) عادة ما تكون أكثر قابلية للقراءة.
لا أحد يحب قراءة سطر أفقي طويل من التعليمات البرمجية. من الأفضل تقسيمها.
على سبيل المثال:
// علامات الاقتباس الخلفية ` تسمح بتقسيم السلسلة إلى أسطر متعددة دع str = ` ECMA International's TC39 هي مجموعة من مطوري JavaScript، المنفذون والأكاديميون وغيرهم، يتعاونون مع المجتمع للحفاظ على تعريف JavaScript وتطويره. `;
وإذا if
البيانات:
لو ( المعرف === 123 && MoonPhase === 'تضاءل الأحدب' && علامة البروج === "الميزان" ) { LetTheSorceryBegin(); }
ينبغي الاتفاق على الحد الأقصى لطول الخط على مستوى الفريق. عادة ما يكون 80 أو 120 حرفًا.
هناك نوعان من المسافات البادئة:
المسافات البادئة الأفقية: 2 أو 4 مسافات.
يتم عمل مسافة بادئة أفقية باستخدام مسافتين أو 4 مسافات أو رمز علامة التبويب الأفقية (مفتاح Tab ). أي واحد للاختيار هو حرب مقدسة قديمة. أصبحت المساحات أكثر شيوعًا في الوقت الحاضر.
تتمثل إحدى ميزات المسافات فوق علامات التبويب في أن المسافات تسمح بتكوينات أكثر مرونة للمسافات البادئة مقارنة برمز علامة التبويب.
على سبيل المثال، يمكننا محاذاة المعلمات مع قوس الفتح، مثل هذا:
عرض (المعلمات، محاذاة، // 5 مسافات الحشو على اليسار واحد، بعد، آخر ) { // ... }
المسافات البادئة الرأسية: أسطر فارغة لتقسيم التعليمات البرمجية إلى كتل منطقية.
حتى وظيفة واحدة يمكن تقسيمها في كثير من الأحيان إلى كتل منطقية. في المثال أدناه، يتم تقسيم تهيئة المتغيرات والحلقة الرئيسية وإرجاع النتيجة عموديًا:
وظيفة الأسرى (س، ن) { دع النتيجة = 1؛ // <-- لـ (دع i = 0; i < n; i++) { النتيجة *= س؛ } // <-- نتيجة الإرجاع؛ }
أدخل سطرًا جديدًا إضافيًا حيث يساعد في جعل الكود أكثر قابلية للقراءة. يجب ألا يكون هناك أكثر من تسعة أسطر من التعليمات البرمجية بدون مسافة بادئة رأسية.
يجب أن تكون هناك فاصلة منقوطة بعد كل عبارة، حتى لو كان من الممكن تخطيها.
هناك لغات تكون فيها الفاصلة المنقوطة اختيارية حقًا ونادرًا ما يتم استخدامها. ومع ذلك، في JavaScript، هناك حالات لا يتم فيها تفسير فاصل الأسطر على أنه فاصلة منقوطة، مما يجعل التعليمات البرمجية عرضة للأخطاء. تعرف على المزيد حول ذلك في الفصل بنية الكود.
إذا كنت من ذوي الخبرة في برمجة JavaScript، فيمكنك اختيار نمط تعليمات برمجية بدون فاصلة منقوطة مثل StandardJS. بخلاف ذلك، فمن الأفضل استخدام الفواصل المنقوطة لتجنب الأخطاء المحتملة. غالبية المطورين يضعون الفواصل المنقوطة.
حاول تجنب تداخل التعليمات البرمجية في العديد من المستويات العميقة.
على سبيل المثال، في الحلقة، من الجيد أحيانًا استخدام توجيه continue
لتجنب التداخل الإضافي.
على سبيل المثال، بدلاً من إضافة شرط if
مثل هذا:
لـ (دع i = 0; i < 10; i++) { إذا (شرط) { ... // <- مستوى تداخل آخر } }
يمكننا أن نكتب:
لـ (دع i = 0; i < 10; i++) { إذا (! cond) يستمر؛ ... // <- لا يوجد مستوى تداخل إضافي }
يمكن فعل شيء مماثل باستخدام if/else
return
.
على سبيل المثال، بنيان أدناه متطابقان.
الخيار 1:
وظيفة الأسرى (س، ن) { إذا (ن <0) { تنبيه ("السلبية غير مدعومة")؛ } آخر { دع النتيجة = 1؛ لـ (دع i = 0; i < n; i++) { النتيجة *= س؛ } نتيجة الإرجاع؛ } }
الخيار 2:
وظيفة الأسرى (س، ن) { إذا (ن <0) { تنبيه ("السلبية غير مدعومة")؛ يعود؛ } دع النتيجة = 1؛ لـ (دع i = 0; i < n; i++) { النتيجة *= س؛ } نتيجة الإرجاع؛ }
أما الحالة الثانية فهي أكثر قابلية للقراءة لأنه يتم التعامل مع "الحالة الخاصة" لـ n < 0
في وقت مبكر. بمجرد الانتهاء من الفحص، يمكننا الانتقال إلى تدفق التعليمات البرمجية "الرئيسي" دون الحاجة إلى تداخل إضافي.
إذا كنت تكتب العديد من الوظائف "المساعدة" والرمز الذي يستخدمها، فهناك ثلاث طرق لتنظيم الوظائف.
قم بتعريف الوظائف الموجودة أعلى الكود الذي يستخدمها:
// إعلانات الوظائف وظيفة إنشاء العنصر () { ... } دالة setHandler(elem) { ... } وظيفة التجول () { ... } // الكود الذي يستخدمها Let elem = createElement(); setHandler(elem); walkAround();
الكود أولًا، ثم الوظائف
// الكود الذي يستخدم الوظائف Let elem = createElement(); setHandler(elem); walkAround(); // --- الوظائف المساعدة --- وظيفة إنشاء العنصر () { ... } دالة setHandler(elem) { ... } وظيفة التجول () { ... }
مختلط: يتم الإعلان عن الوظيفة حيث تم استخدامها لأول مرة.
في أغلب الأحيان، يُفضل الخيار الثاني.
وذلك لأنه عند قراءة التعليمات البرمجية، نريد أولاً أن نعرف ما الذي يفعله . إذا تم كتابة الكود أولاً، فسيصبح واضحًا من البداية. بعد ذلك، ربما لن نحتاج إلى قراءة الوظائف على الإطلاق، خاصة إذا كانت أسماؤها تصف ما تفعله بالفعل.
يحتوي دليل الأسلوب على قواعد عامة حول "كيفية كتابة" التعليمات البرمجية، على سبيل المثال، علامات الاقتباس التي يجب استخدامها، وعدد المسافات البادئة، والحد الأقصى لطول السطر، وما إلى ذلك. وهناك الكثير من الأشياء الصغيرة.
عندما يستخدم جميع أعضاء الفريق دليل النمط نفسه، يبدو الرمز موحدًا، بغض النظر عن عضو الفريق الذي قام بكتابته.
بالطبع، يمكن للفريق دائمًا كتابة دليل أسلوبه الخاص، ولكن عادةً لا تكون هناك حاجة لذلك. هناك العديد من الأدلة الموجودة للاختيار من بينها.
بعض الاختيارات الشعبية:
دليل نمط جافا سكريبت من جوجل
دليل أسلوب جافا سكريبت الخاص بـ Airbnb
اصطلاحي.JS
StandardJS
(بالإضافة إلى الكثير غيرها)
إذا كنت مطورًا مبتدئًا، فابدأ بورقة الغش في بداية هذا الفصل. ثم يمكنك تصفح أدلة الأنماط الأخرى لالتقاط المزيد من الأفكار وتحديد الفكرة التي تفضلها.
تعتبر Linters أدوات يمكنها التحقق تلقائيًا من نمط التعليمات البرمجية الخاصة بك وتقديم اقتراحات للتحسين.
والشيء الرائع فيها هو أن التحقق من النمط يمكن أن يعثر أيضًا على بعض الأخطاء، مثل الأخطاء المطبعية في أسماء المتغيرات أو الوظائف. بسبب هذه الميزة، يوصى باستخدام linter حتى إذا كنت لا تريد الالتزام بـ "نمط رمز" معين.
فيما يلي بعض أدوات الفحص المعروفة:
JSLint – واحدة من أولى الشركات.
JSHint – إعدادات أكثر من JSLint.
ESLint – ربما هو الأحدث.
كلهم يستطيعون القيام بهذه المهمة. يستخدم المؤلف ESLint.
يتم دمج معظم أجهزة Linters مع العديد من المحررين المشهورين: ما عليك سوى تمكين المكون الإضافي في المحرر وتكوين النمط.
على سبيل المثال، بالنسبة لـ ESLint، يجب عليك القيام بما يلي:
قم بتثبيت Node.js.
قم بتثبيت ESLint باستخدام الأمر npm install -g eslint
(npm عبارة عن مثبت حزمة JavaScript).
قم بإنشاء ملف تكوين باسم .eslintrc
في جذر مشروع JavaScript الخاص بك (في المجلد الذي يحتوي على جميع ملفاتك).
قم بتثبيت/تمكين البرنامج الإضافي لمحررك الذي يتكامل مع ESLint. غالبية المحررين لديهم واحد.
فيما يلي مثال لملف .eslintrc
:
{ "يمتد": "eslint:موصى به", "بيئة": { "المتصفح": صحيح، "العقدة": صحيح، "es6": صحيح }, "قواعد": { "بدون وحدة تحكم": 0، "مسافة بادئة": 2 } }
يشير التوجيه "extends"
هنا إلى أن التكوين يعتمد على مجموعة الإعدادات "eslint:recommulated". بعد ذلك نحدد منطقتنا.
من الممكن أيضًا تنزيل مجموعات قواعد الأنماط من الويب وتوسيعها بدلاً من ذلك. راجع https://eslint.org/docs/user-guide/getting-started لمزيد من التفاصيل حول التثبيت.
تحتوي بعض بيئات التطوير المتكاملة أيضًا على فحص مدمج، وهو أمر مريح ولكنه غير قابل للتخصيص مثل ESLint.
تهدف جميع قواعد بناء الجملة الموضحة في هذا الفصل (وفي أدلة الأسلوب المشار إليها) إلى زيادة سهولة قراءة التعليمات البرمجية الخاصة بك. كلها قابلة للنقاش.
عندما نفكر في كتابة كود "أفضل"، فإن الأسئلة التي يجب أن نطرحها على أنفسنا هي: "ما الذي يجعل الكود أكثر قابلية للقراءة وأسهل للفهم؟" و"ما الذي يمكن أن يساعدنا في تجنب الأخطاء؟" هذه هي الأشياء الأساسية التي يجب وضعها في الاعتبار عند اختيار أنماط التعليمات البرمجية ومناقشتها.
ستسمح لك قراءة أدلة الأنماط الشائعة بمواكبة أحدث الأفكار حول اتجاهات أنماط التعليمات البرمجية وأفضل الممارسات.
الأهمية: 4
ما الخطأ في نمط الكود أدناه؟
وظيفة الأسرى (س، ن) { دع النتيجة = 1؛ ل(دع i=0;i<n;i++) {result*=x;} نتيجة الإرجاع؛ } دع x=prompt("x؟",''), n=prompt("n؟",'') إذا (ن<=0) { تنبيه ("الطاقة ${n} غير مدعومة، يرجى إدخال رقم صحيح أكبر من الصفر")؛ } آخر { تنبيه (الأسير (س، ن)) }
أصلحه.
يمكنك ملاحظة ما يلي:
الدالة pow(x,n) // <- لا توجد مسافة بين الوسائط { // <- قوس الشكل على سطر منفصل دع النتيجة = 1؛ // <- لا توجد مسافات قبل أو بعد = for(let i=0;i<n;i++) {result*=x;} // <- بدون مسافات // يجب أن تكون محتويات { ... } في سطر جديد نتيجة الإرجاع؛ } Let x=prompt("x؟",''), n=prompt("n؟",'') // <-- ممكن تقنيًا، // ولكن من الأفضل أن تجعله سطرين، كما لا توجد مسافات أو مفقودة؛ if (n<=0) // <- لا توجد مسافات داخل (n <= 0)، ويجب أن يكون هناك سطر إضافي فوقها { // <- قوس الشكل على سطر منفصل // أدناه - يمكن تقسيم الأسطر الطويلة إلى أسطر متعددة لتحسين إمكانية القراءة تنبيه ("الطاقة ${n} غير مدعومة، يرجى إدخال رقم صحيح أكبر من الصفر")؛ } else // <- يمكن كتابته على سطر واحد مثل "} else {" { تنبيه (pow(x,n)) // لا يوجد مسافات ومفقود ; }
البديل الثابت:
وظيفة الأسرى (س، ن) { دع النتيجة = 1؛ لـ (دع i = 0; i < n; i++) { النتيجة *= س؛ } نتيجة الإرجاع؛ } دع x = موجه("x؟", ""); Let n = موجه("n؟", ""); إذا (ن <= 0) { تنبيه ("الطاقة ${n} غير مدعومة،" الرجاء إدخال رقم صحيح أكبر من الصفر`)؛ } آخر { تنبيه( الأسرى(x, n)); }