13 نقطة جديرة بالملاحظة من دليل أسلوب جافا سكريبت من Google

بالنسبة لأي شخص ليس على دراية به بالفعل ، تضع Google دليل أسلوب لكتابة JavaScript الذي يحدد (ما تعتقد Google أنه) أفضل الممارسات الأسلوبية لكتابة كود واضح ومفهوم.

هذه ليست قواعد صارمة وسريعة لكتابة JavaScript صالحة ، فقط محظورات للحفاظ على خيارات نمط متسقة وجذابة في جميع ملفات المصدر الخاصة بك. هذا مثير للاهتمام بشكل خاص لجافا سكريبت ، وهي لغة مرنة ومتسامحة تتيح مجموعة متنوعة من الخيارات الأسلوبية.

لدى Google و Airbnb اثنين من أشهر أدلة الأنماط المتوفرة. أوصي بالتأكيد بالتحقق من كليهما إذا كنت تقضي وقتًا طويلاً في كتابة JS.

فيما يلي ثلاثة عشر من القواعد التي أعتقد أنها الأكثر إثارة للاهتمام وذات الصلة من دليل أسلوب JS من Google.

إنهم يتعاملون مع كل شيء بدءًا من المشكلات المتنازع عليها بشدة (علامات التبويب مقابل المسافات ، والمسألة المثيرة للجدل حول كيفية استخدام الفاصلة المنقوطة) ، إلى بعض المواصفات الأكثر غموضًا التي فاجأتني. سيغيرون بالتأكيد الطريقة التي أكتب بها JS الخاصة بي في المستقبل.

لكل قاعدة ، سأقدم ملخصًا للمواصفات ، متبوعًا باقتباس داعم من دليل النمط الذي يصف القاعدة بالتفصيل. عند الاقتضاء ، سأقدم أيضًا مثالًا على الأسلوب في الممارسة ، وأقارنه بالرمز الذي لا يتبع القاعدة.

استخدم المسافات ، وليس علامات التبويب

بصرف النظر عن تسلسل فاصل السطر ، فإن حرف المسافة الأفقية ASCII (0x20) هو حرف المسافة البيضاء الوحيد الذي يظهر في أي مكان في الملف المصدر. هذا يعني أن… لا يتم استخدام أحرف الجدولة للمسافة البادئة.

يحدد الدليل لاحقًا أنه يجب عليك استخدام مسافتين (وليس أربعة) للمسافة البادئة.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

الفاصلة المنقوطة مطلوبة

يجب إنهاء كل عبارة بفاصلة منقوطة. الاعتماد على الإدراج التلقائي للفاصلة المنقوطة ممنوع.

على الرغم من أنني لا أستطيع أن أتخيل سبب معارضة أي شخص لهذه الفكرة ، إلا أن الاستخدام المتسق للفواصل المنقوطة في JS أصبح النقاش الجديد حول "المسافات مقابل علامات التبويب". جوجل يخرج بقوة هنا للدفاع عن الفاصلة المنقوطة.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

لا تستخدم وحدات ES6 (حتى الآن)

لا تستخدم وحدات ES6 بعد (أي exportو importكلمة مرور)، ومعاني الكلمات ولم تستكمل بعد. لاحظ أنه ستتم مراجعة هذه السياسة بمجرد أن تصبح الدلالات قياسية تمامًا.
// Don't do this kind of thing yet:
//------ lib.js ------export function square(x) { return x * x;}export function diag(x, y) { return sqrt(square(x) + square(y));}//------ main.js ------import { square, diag } from 'lib';

المحاذاة الأفقية غير مستحبة (ولكن ليس ممنوعًا)

هذه الممارسة مسموح بها ، ولكن لا تشجعها Google Style بشكل عام. ليس من الضروري حتى الحفاظ على المحاذاة الأفقية في الأماكن التي تم استخدامها فيها بالفعل.

المحاذاة الأفقية هي ممارسة إضافة عدد متغير من المسافات الإضافية في التعليمات البرمجية الخاصة بك ، لجعل الرموز المميزة تظهر مباشرة أسفل بعض الرموز الأخرى في الأسطر السابقة.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

لا تستخدم فار بعد الآن

قم بتعريف جميع المتغيرات المحلية باستخدام constأو let. استخدم const افتراضيًا ، ما لم يحتاج المتغير إلى إعادة تعيينه. و varيجب عدم استخدام الكلمة.

ما زلت أرى أشخاصًا يستخدمون varنماذج التعليمات البرمجية في StackOverflow وفي أماكن أخرى. لا يمكنني معرفة ما إذا كان هناك أشخاص في الخارج سيقدمون حجة لذلك ، أم أنها مجرد حالة عادات قديمة تموت بشدة.

// badvar example = 42;
// goodlet example = 42;

يفضل استخدام وظائف السهم

توفر وظائف Arrow صياغة موجزة وإصلاح عدد من الصعوبات في this. تفضل وظائف السهم على functionالكلمة الأساسية ، خاصة للوظائف المتداخلة

سأكون صريحًا ، لقد اعتقدت للتو أن وظائف السهم كانت رائعة لأنها كانت أكثر إيجازًا وأجمل في النظر إليها. تبين أنها تخدم أيضًا غرضًا مهمًا جدًا.

// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});

استخدم سلاسل النموذج بدلاً من التسلسل

استخدم سلاسل القوالب (المحددة بـ `) عبر تسلسل السلسلة المعقدة ، خاصةً إذا تم تضمين العديد من السلاسل الحرفية. قد تمتد سلاسل القالب على عدة أسطر.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}

لا تستخدم استمرار الخط مع السلاسل الطويلة

لا تستخدم استمرارية السطر (أي إنهاء سطر داخل سلسلة حرفية بشرطة مائلة للخلف) في القيم الحرفية العادية أو النموذجية. على الرغم من أن ES5 يسمح بذلك ، إلا أنه يمكن أن يؤدي إلى أخطاء خادعة إذا ظهرت أي مسافة بيضاء زائدة بعد الشرطة المائلة ، وكانت أقل وضوحًا للقراء.

ومن المثير للاهتمام أن هذه قاعدة لا تتفق عليها Google و Airbnb (ها هي مواصفات Airbnb).

بينما توصي Google بتسلسل سلاسل أطول (كما هو موضح أدناه) يوصي دليل أسلوب Airbnb بعدم القيام بأي شيء بشكل أساسي ، والسماح للخيوط الطويلة بالاستمرار طالما احتاجوا إلى ذلك.

// bad (sorry, this doesn't show up well on mobile)const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.';
// goodconst longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';

"for… of" هو النوع المفضل من "for loop"

مع ES6 ، تحتوي اللغة الآن على ثلاثة أنواع مختلفة من forالحلقات. يمكن استخدام كل شيء ، على الرغم من ذلك for- ofيجب تفضيل الحلقات عندما يكون ذلك ممكنًا.

هذا أمر غريب إذا سألتني ، لكنني اعتقدت أنني سأقوم بتضمينه لأنه من المثير للاهتمام أن تعلن Google عن نوع forالحلقة المفضل .

كنت دائمًا تحت انطباع أن for... inالحلقات كانت أفضل للأشياء ، بينما for... ofكانت أكثر ملاءمة للمصفوفات. أداة مناسبة للوظيفة المناسبة.

في حين أن مواصفات Google هنا لا تتعارض بالضرورة مع هذه الفكرة ، فلا يزال من المثير للاهتمام معرفة أن لديهم تفضيلًا لهذه الحلقة على وجه الخصوص.

لا تستخدم EVAL ()

لا تستخدم evalأو Function(...string)المُنشئ (باستثناء برامج تحميل الكود). من المحتمل أن تكون هذه الميزات خطرة ولا تعمل ببساطة في بيئات الطاقة الشمسية المركزة.

تحتوي صفحة MDN الخاصة eval()بها أيضًا على قسم يسمى "لا تستخدم EVAL!"

// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

يجب تسمية الثوابت في ALL_UPPERCASE مفصولة بشرطة سفلية

تستخدم الأسماء الثابتة CONSTANT_CASE: جميع الأحرف الكبيرة ، مع فصل الكلمات بشرطة سفلية.

إذا كنت متأكدًا تمامًا من أنه لا يجب تغيير المتغير ، يمكنك الإشارة إلى ذلك بكتابة اسم الثابت بأحرف كبيرة. هذا يجعل ثبات الثابت واضحًا حيث يتم استخدامه في جميع أنحاء التعليمات البرمجية الخاصة بك.

الاستثناء الملحوظ لهذه القاعدة هو إذا كان الثابت متعلقًا بنطاق الوظيفة. في هذه الحالة يجب أن تكتب في حالة الجمل.

// badconst number = 5;
// goodconst NUMBER = 5;

متغير واحد لكل إعلان

يصرح كل إعلان عن متغير محلي عن متغير واحد فقط: التصريحات مثل let a = 1, b = 2;لا تستخدم.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

استخدم علامات الاقتباس المفردة ، وليس علامات الاقتباس المزدوجة

يتم تحديد القيم الحرفية للسلسلة العادية بعلامات اقتباس مفردة ( ') ، بدلاً من علامات الاقتباس المزدوجة ( "). نصيحة: إذا كانت السلسلة تحتوي على حرف اقتباس واحد ، ففكر في استخدام سلسلة نصية لتجنب الاضطرار إلى تجاوز علامة الاقتباس.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

ملاحظة أخيرة

كما قلت في البداية ، هذه ليست ولايات. جوجل هو مجرد واحد من العديد من عمالقة التكنولوجيا ، وهذه مجرد توصيات.

ومع ذلك ، من المثير للاهتمام إلقاء نظرة على توصيات الأنماط التي تقدمها شركة مثل Google ، والتي توظف الكثير من الأشخاص اللامعين الذين يقضون الكثير من الوقت في كتابة كود ممتاز.

يمكنك اتباع هذه القواعد إذا كنت ترغب في اتباع الإرشادات الخاصة بـ "شفرة المصدر المتوافقة مع Google" - ولكن ، بالطبع ، يختلف الكثير من الأشخاص ، ولك مطلق الحرية في التخلص من أي من هذا أو كله.

أنا شخصياً أعتقد أن هناك الكثير من الحالات التي تكون فيها مواصفات Airbnb أكثر جاذبية من مواصفات Google. بغض النظر عن الموقف الذي تتخذه من هذه القواعد المحددة ، لا يزال من المهم مراعاة الاتساق الأسلوبي عند كتابة أي نوع من التعليمات البرمجية.