مقدمة:
يعد نمط الترميز للغة البرمجة أمرًا مهمًا للغاية لبرنامج الصيانة على المدى الطويل ، وخاصة في العمل الجماعي. إذا كان الفريق يستخدم نمط ترميز موحد وموحد ، فيمكنه تحسين مستوى تعاون الفريق وكفاءة العمل. في قلب دليل نمط البرمجة ، توجد قواعد تنسيق أساسية تحدد كيفية كتابة التعليمات البرمجية عالية المستوى. يأتي هذا الدليل من كتاب "كتابة JavaScript" ، استنادًا إلى "مواصفات ترميز لغة Java" ومواصفات برمجة JavaScript من Crockford ، بالإضافة إلى بعض الخبرة الشخصية وتفضيلات Nicbolas. الغرض من كتابة هذا المقال هو تعميق انطباعك ، وجعل المزيد من الناس يفهمون أسلوب ترميز JS وتحسين جودة الترميز الخاصة بهم. لمزيد من المعلومات ، يرجى قراءة "كتابة JavaScript القابلة للصيانة".
1. المسافة البادئة
يتكون مستوى كل صف من 4 مسافات ، وتجنب المسافة البادئة باستخدام علامة التبويب.
// طريقة كتابة جيدة إذا (صواب) {dosomething () ؛}2. طول الصف
يجب ألا يتجاوز كل سطر 80 حرفًا. إذا تجاوز الخط 80 حرفًا ، فيجب كسره بعد المشغل. يجب أن يضيف السطر التالي مستويين من المسافة البادئة (8 أحرف).
// طريقة الكتابة الجيدة dosomething (الوسيطة 1 ، الوسيطة 2 ، AeGment3 ، PINGUMINE4 ، PINGUMINE5) ؛ // طريقة الكتابة السيئة: dosomething (PINGUMINE1 ، PINGUMENT2 ، AEGMENT3 ، PINGUMITY 4 ، PINCITION5) ؛
3. القيمة الأصلية
يجب أن تستخدم السلاسل دائمًا عروض أسعار مزدوجة والحفاظ على سطر واحد ، وتجنب استخدام القطع المائلة لبدء سطر واحد في السلسلة.
يجب أن تستخدم الأرقام الأعداد الصحيحة العشرية ، وتمثل الخوارزميات العلمية الأعداد الصحيحة أو الأعداد الصحيحة السداسية أو العشرية العشرية العشرية. يجب الاحتفاظ رقم واحد على الأقل قبل وبعد العشري. تجنب استخدام كميات أوكتال مباشرة.
يجب تجنب القيمة الخاصة الفارغة إلا في الحالات التالية.
• يستخدم لتهيئة متغير ، والذي يمكن تعيين قيمة لكائن.
• يستخدم للمقارنة مع متغير تهيئته ، والذي يمكن أن يكون أو ليس كائن.
• عندما من المتوقع أن تكون معلمة الوظيفة كائنًا ، يتم تمريرها كمعلمة.
• عندما من المتوقع أن تكون قيمة إرجاع الوظيفة كائنًا ، يتم تمريرها كقيمة الإرجاع.
تجنب استخدام القيم الخاصة غير المحددة. لتحديد ما إذا كان يتم تعريف المتغير ، يجب استخدام مشغل typeof.
4. تباعد المشغل
يجب استخدام المساحة قبل وبعد الميزانية الثنائية للحفاظ على التعبير أنيق. يشمل المشغلون مشغلي المهام والمشغلين المنطقيين.
// الكتابة الجيدة لـ (var i = 0 ؛ i <count ؛ i ++) {Process (i) ؛} // الكتابة السيئة: الفضاء المفقود لـ (var i = 0 ؛ i <count ؛ i ++) {process (i) ؛}5. تباعد قوسين
عند استخدام الأقواس ، يجب ألا يكون هناك مساحة مباشرة بعد القوس الأيسر مباشرة قبل القوس القريب.
// الكتابة الجيدة لـ (var i = 0 ؛ i <count ؛ i ++) {process (i) ؛} // الكتابة السيئة: هناك مسافات إضافية على جانبي المعلمة (var i = 0 ؛ i <count ؛ i ++) {process (i) ؛}6. قياس الكائن المباشر
يجب أن يكون للكمية المباشرة للكائن التنسيق التالي.
• يجب أن تبقى أقواس البداية اليسرى على نفس خط التعبير.
• يجب إبقاء قيمة اسم كل سمة مسافة بادئة ، ويجب أن تكون السمة الأولى خطًا جديدًا بعد الدعامة المجعد اليسرى.
• يجب استخدام قيمة اسم كل سمة بدون علامات اقتباس ، تليها القولون (قبل المساحة) ، تليها قيمة.
• إذا كانت قيمة السمة هي نوع وظيفة ، فيجب أن يبدأ جسم الوظيفة خطًا جديدًا تحت اسم السمة ، ويجب الاحتفاظ بخط فارغ قبل وبعده.
• يمكن إدراج أسطر فارغة قبل وبعد مجموعة من الخصائص ذات الصلة لتحسين قابلية قراءة الكود.
• يجب أن تشغل الدعامة اليمنى النهائية سطرًا واحدًا حصريًا.
// طريقة كتابة جيدة var object = {key1: value1 ، key2: value2 ، func: funct () {// dosomething} ، key3: value3} ؛ {// dosomething} ، key3: value3} ؛عند استخدام الكائن الحرفي كمعلمة دالة ، إذا كانت القيمة متغيرًا ، فيجب أن تكون أقواس البداية على نفس سطر اسم الوظيفة. جميع القواعد الأخرى المدرجة مسبقًا تنطبق أيضًا.
// طريقة كتابة جيدة dosomething ({key1: value1 ، key2: value2}) ؛ // طريقة الكتابة السيئة: جميع الرموز dosomething ({key1: value1 ، key2: value2}) ؛7. التعليقات
يمكن أن يساعد استخدام التعليقات الموجزة والواضحة للآخرين على فهم الكود الخاص بك. يجب استخدام التعليقات في المواقف التالية.
• الرمز غامض.
• الرموز التي قد تكون خاطئة للخطأ.
• رمز المتصفح الضروري ولكن ليس واضحًا.
• بالنسبة للكائنات أو الأساليب أو الخصائص ، من الضروري إنشاء مستندات (باستخدام تعليقات المستند المناسبة).
التعليقات خط واحد
يجب استخدام تعليقات الخط الواحد لتوضيح سطر واحد من التعليمات البرمجية أو مجموعة من الرموز ذات الصلة. قد تكون هناك ثلاث طرق لاستخدام تعليقات الخط الواحد.
• تعليقات حصرية لشرح السطر التالي من الكود.
• التعليقات في نهاية سطر الكود لشرح الرمز قبل ذلك.
• خطوط متعددة للتعليق على كتلة من الكود.
// كتابة جيدة إذا (الشرط) {// إذا تم تنفيذ الكود هنا ، فهذا يعني أنه تم تمرير جميع عمليات فحص الأمن ؛} // الكتابة السيئة: لا يوجد سطر فارغ قبل التعليق إذا (الشرط) {// إذا تم تنفيذ الكود هنا ، فهذا يعني أنه تم تنفيذ جميع عمليات التحقق من الأمان ؛ تم تمريره ؛} // الكتابة السيئة: يجب استخدام التعليقات متعددة الخطوط // يتم استخدام قطعة الكود هذه لـ ** الحكم // ثم إذا (الشرط) {// إذا تم تنفيذ الكود هنا ، فهذا يعني أن جميع عمليات التحقق من الأمان قد تم تمريرها ؛ مسموح()؛ // تنفيذ وظيفة **} // الضعيفة الكتابة: لا توجد مسافات كافية بين الكود والتعليق إذا (الشرط) {// إذا تم تنفيذ الكود هنا ، فهذا يعني أنه تم تمرير جميع عمليات الفحص الأمنية () ؛ // تنفيذ وظيفة ** // الكتابة الجيدة: عند التعليق على كتلة رمز ، يجب عليك الاتصال لاستخدام تعليق سطر واحد ، ويجب عدم استخدام التعليقات متعددة الخطوط في هذه الحالة. // if (شرط) {// مسموح به () ؛ // تنفيذ ** الدالة //}تعليقات متعددة الخطوط
يجب استخدام التعليقات متعددة الخطوط عندما يحتاج الرمز إلى المزيد من النص لتفسيره. يحتوي كل تعليق متعدد الخطوط على ثلاثة أسطر على الأقل على النحو التالي:
1. السطر الأول يتضمن فقط بدء /* تعليق التعليق. يجب ألا يكون هناك نص آخر في هذا الخط.
2. تبدأ الخطوط التالية بـ * وتبقى محاذاة اليسار. هذه يمكن وصفها بالكلمات.
3. يبدأ السطر الأخير بـ */ ويبقى محاذاة مع السطر السابق. يجب ألا يكون هناك نص آخر.
يجب أن يحافظ السطر الأول من التعليق متعدد الخطوط على نفس المستوى من المسافة البادئة كما يصف الرمز. يجب أن يكون لكل سطر لاحق نفس المستوى من المسافة البادئة ومساحة متصلة (للحفاظ على محاذاة الأحرف * بشكل صحيح). يجب حجز سطر فارغ قبل كل رمز متعدد الخطوط.
// طريقة كتابة جيدة ، إذا (الشرط) {/** إذا تم تنفيذ الكود هنا* فهذا يعني أنه تم تمرير جميع عمليات اكتشاف الأمن*/ مسموح بها () ؛}بيان التعليق
يمكن في بعض الأحيان استخدام التعليقات لإعلان معلومات إضافية إلى جزء من الكود. يبدأ تنسيق هذه العبارات بكلمة واحدة ويتبعه القولون على الفور. العبارات التي يمكن استخدامها على النحو التالي.
TODO: لم يكتمل رمز الوصف بعد. يجب أن يشمل ما تريد القيام به بعد ذلك.
الاختراق: إنه يوضح أن تطبيق الكود قد اتخذ اختصارًا. يجب أن تشمل أسباب استخدام الاختراقات. قد يشير هذا أيضًا إلى أنه قد يكون هناك حل أفضل للمشكلة.
xxx: اشرح أن الكود يمثل مشكلة ويجب إصلاحه في أقرب وقت ممكن.
FixMe: اشرح أن الكود يمثل مشكلة ويجب إصلاحه في أقرب وقت ممكن. إنه في المرتبة الثانية قليلاً إلى xxx.
المراجعة: يجب مراجعة رموز التعليمات في أي تغييرات محتملة.
يمكن استخدام هذه الإعلانات في تعليق واحد أو أكثر ويجب أن تتبع نفس قواعد التنسيق مثل نوع التعليق العام.
8. تسمية
يجب أن تكون المتغيرات والوظائف حذرة عند تسميةها. يجب أن يقتصر التسمية على الأحرف الأبجدية العددية ، ويمكن استخدام السطحية السفلية (_) في بعض الحالات. من الأفضل عدم استخدام علامة الدولار ($) أو backslash (/) في أي تسمية.
يجب أن تكون التسمية المتغيرة في تنسيق تسمية الجمل ، مع الحرف الأولى الصغيرة والحرف الأول من كل كلمة كبيرة. يجب أن تكون الكلمة الأولى من الاسم المتغير اسمًا (وليس فعلًا) لتجنب الالتباس مع نفس الوظيفة. لا تستخدم السفقة السفلية في أسماء متغيرة.
// طريقة كتابة جيدة var accountNumber = "test001" ؛ // طريقة الكتابة السيئة: ابدأ بحرف رأس المال var accountnumber = "test001" ؛
يجب أن تكون أسماء الوظائف أيضًا بتنسيق تسمية الجمل. يجب أن تكون الكلمة الأولى من اسم الوظيفة فعلًا (وليس اسمًا) لتجنب الالتباس مع المتغير نفسه. من الأفضل عدم استخدام الأسماء السفلية في أسماء الوظائف.
// وظيفة الكتابة الجيدة دالة dosomething () {// code} // طريقة الكتابة السيئة: دالة dosomething () {// code} // طريقة الكتابة السيئة: الوظيفة شيء () {// code} // طريقة الكتابة السيئة: استخدم وظيفة underscore do_something () {// code}يجب أيضًا تسمية المُنشئ - وهي وظيفة تنشئ كائنًا جديدًا من خلال المشغل الجديد - بتنسيق الجمل ويتم رسملة الشخصية الأولى. يجب أن يبدأ اسم المنشئ بغير غير مرغوب فيه ، لأن الجديد يمثل تشغيل مثيل لكائن.
// طريقة كتابة جيدة وظيفة myObject () {// code} // طريقة الكتابة السيئة: وظيفة myObject () في بداية الأحرف الصغيرة {// code} // طريقة الكتابة السيئة: استخدم وظيفة underscore my_object () {// code} // طريقة الكتابة السيئة: وظيفة في الفراد getMyoBject () {// code}يجب أن تكون اسم الثوابت (المتغيرات التي لا تتغير قيمها) جميع الحروف الرأسمالية ، مفصولة بواسطة واحد ترسيح بين الكلمات المختلفة.
// طريقة كتابة جيدة var total_count = 10 ؛ // طريقة الكتابة السيئة: نموذج الإبل var totalCount = 10 ؛ // طريقة الكتابة السيئة: نموذج مختلط var total_count = 10 ؛
سمات الكائنات هي نفس سمات المتغيرات. طرق الكائنات هي نفس أساليب الوظائف. إذا كان العقار أو الطريقة خاصة ، فيجب إضافة السطح السفلي قبل ذلك.
// طريقة كتابة جيدة var object = {_count: 10،4 _getCount: function () {return this._count ؛ }}9. إعلانات متغير ووظيفة
إعلان متغير
يجب تحديد جميع المتغيرات مقدمًا قبل الاستخدام. يجب وضع التعريفات المتغيرة في بداية الوظيفة ، باستخدام تعبير VAR متغير لكل سطر. باستثناء الصف الأول ، يجب وضع مسافة بادئة لجميع الصفوف طبقة أخرى بحيث يمكن محاذاة الأسماء المتغيرة رأسياً. يجب تهيئة التعريفات المتغيرة ويجب على مشغلي المهام الحفاظ على المسافة البادئة المتسقة. يجب أن يكون المتغير المهيئة قبل تهيئة المتغير.
// طريقة كتابة جيدة var count = 10 ، name = "jeri" ، تم العثور عليها = خطأ ، فارغ ؛
إعلان الوظيفة
يجب تحديد الوظائف مقدمًا قبل الاستخدام. يجب أن تستخدم الوظيفة التي ليست طريقة (أي ، لا توجد سمة ككائن) التنسيق المحدد بواسطة الوظيفة (وليس تنسيق تعبير الوظيفة وتنسيق وظائف الوظيفة). لا ينبغي أن يكون هناك مساحة بين اسم الوظيفة والأقواس البدء. يجب ترك مساحة بين قوسين النهاية والأقواس المجعد على اليمين. يجب أن تظل أقواس مجعد على اليمين على نفس خط الكلمة الرئيسية للدالة. يجب ألا يكون هناك مساحة بين قوسين البداية والنهاية. يجب ترك مساحة بعد فاصلة بين أسماء المعلمات. يجب أن يظل جسم الوظيفة مسافة بادئة في المستوى الأول.
// وظيفة الكتابة الجيدة وظيفة OUTER () {var count = 10 ، name = "jeri" ، تم العثور عليها = false ، فارغة ؛ الدالة inner () {// code} // code التي تستدعي Inner ()}يمكن تعيين وظائف مجهولة كطرق للكائنات ، أو كمعلمات لوظائف أخرى. لا ينبغي أن يكون هناك مساحة بين الكلمة الرئيسية للوظيفة وقوس البدء.
// طريقة كتابة جيدة Object.method = function () {// code} ؛ // طريقة الكتابة السيئة: object object.method = function () {// code} ؛يجب أن يتم لف الوظيفة التي تسمى على الفور بين قوسين حديقة على الطبقة الخارجية من استدعاء الوظيفة.
// طريقة جيدة var value = (function () {// function body return {message: "hi"}} ()) ؛وضع صارم
يجب استخدام الوضع الصارم فقط داخل الوظائف ويجب عدم استخدامه على مستوى العالم.
// طريقة الكتابة السيئة: استخدم الوضع الصارم "استخدام صارم" ؛ دالة dosomething () {// code} // طريقة الكتابة الجيدة دالة dosomething () {"use strict" ؛ // شفرة}10. المشغلين
تكليف
عند تعيين قيمة لمتغير ، إذا كان الجانب الأيمن عبارة عن تعبير يحتوي على عبارة مقارنة ، فيجب أن يتم لفه بين قوسين.
// كتابة جيدة var flag = (i <count) ؛ // الكتابة السيئة: أقواس مفقودة var flag = i <count ؛
مشغل علامة متساوية
استخدم === (متساوٍ تمامًا) و! == (غير متكافئ تمامًا) بدلاً من == (متساوٍ) و! = (عدم المساواة) لتجنب أخطاء التحويل الضعيفة.
// كتابة جيدة var same = (a === b) ؛ // الكتابة الجيدة var same = (a == b) ؛
عامل ثلاثي
يجب استخدام المشغل الثلاثي فقط في عبارات التعيين المشروطة ويجب عدم استخدامه كبديل عن البيانات.
// طريقة كتابة جيدة var value = الشرط؟ Value1: Value2 ؛ // طريقة الكتابة السيئة: لا توجد مهمة ، إذا كان ينبغي استخدام التعبير؟ dosomething (): dosomethingelse ؛
11. بيان
بيان بسيط
يحتوي كل سطر على بيان واحد فقط على الأكثر. يجب أن تنتهي جميع العبارات البسيطة باستخدام فاصلة فاصلة (؛).
// طريقة كتابة جيدة count ++ ؛ a = b ؛ // طريقة الكتابة السيئة: تتم كتابة تعبيرات متعددة في عدد خط واحد ++ ؛ أ = ب ؛
بيان العودة
لا ينبغي لف عبارات الإرجاع بين قوسين عند إرجاع قيمة ، ما لم يكن ذلك في بعض الحالات قد يجعل قيمة الإرجاع أسهل في الفهم. على سبيل المثال:
إرجاع ؛ إرجاع مجموعة.
بيانات مركب
بيان مركب هو قائمة بالبيانات المحاطة بأقواس.
• يجب وضع مسافة بادئة للبيان المرفق أكثر من بيان المركب.
• يجب أن تكون أقواس البداية في نهاية الخط حيث يوجد بيان المركب ؛ يجب أن تشغل الأقواس النهائية سطرًا واحدًا وتظل بادئة مثل بداية بيان المركب.
• عندما يكون البيان جزءًا من بنية التحكم ، مثل ما إذا كان أو للبيانات ، يجب إرفاق جميع العبارات في أقواس ، بما في ذلك بيان واحد. هذه الاتفاقية تجعل من السهل علينا إضافة عبارات دون القلق بشأن نسيان إضافة قوسين والتسبب في الأخطاء.
• الكلمات الرئيسية لبيان مثل إذا كان يجب أن تبدأ ، تليها مساحة ، ويجب أن تتبع أقواس البداية مساحة.
إذا كان البيان
يجب أن يكون البيان IF بالتنسيق التالي.
إذا (الشرط) {عبارات} إذا (الشرط) {عبارات} آخر {عبارات} if (شرط) {عبارات} آخر إذا (الشرط) {عبارات} else {tatements}لا يُسمح أبدًا بحذف الأقواس المجعد إذا كانت البيانات.
// الكتابة الجيدة إذا (الشرط) {dosomething () ؛} // الكتابة السيئة: مساحات غير لائقة إذا (الشرط) {dosomething () ؛} // الكتابة السيئة: كل الكود على سطر واحد إذا (الشرط) {dosomething () ؛ } // الكتابة السيئة: كل الكود على سطر واحد ولا توجد أقواس مجعد إذا كان (حالة) dosomething () ؛للبيان
يجب أن تكون عبارات النوع بالتنسيق التالي.
لـ (التهيئة ؛ الشرط ؛ التحديث) {عبارات} لـ (متغير في الكائن) {عبارات}لا ينبغي أن يكون لجزء التهيئة من البيان من أجل إعلانات متغيرة.
// طريقة جيدة var i ، len ؛ for (i = 0 ، len = 0 ؛ i <len ؛ i ++) {// code} // bad write: dense ariable for (var i = 0 ، len = 0 ؛ i <len ؛ i ++) {// code} // bad writing: denare for (var prop inbour) {// code}عند استخدام عبارة for-in ، تذكر استخدام HasownProperty () للتحقق المزدوج لتصفية أعضاء الكائن.
بينما بيان
يجب أن تكون عبارات الفئة أثناء الفئة بالتنسيق التالي.
بينما (الشرط) {عبارات}هل البيان
يجب أن تكون بيانات الفئة DO بالتنسيق التالي.
هل {عبارات} بينما (الشرط) ؛بيان التبديل
يجب أن تكون عبارات فئة التبديل بالتنسيق التالي.
التبديل (التعبير) {حالة التعبير: البيانات الافتراضية: عبارات}يجب إبقاء الحالة الأولى تحت المفتاح بادئة. كل حالة ما عدا الأول ، بما في ذلك الافتراضي ، يجب أن تحتفظ بخط فارغ قبل ذلك.
يجب أن تنتهي كل مجموعة من العبارات (باستثناء الافتراضي) بكسر أو إرجاع أو رمي أو تخطي مع مجموعة من التعليقات.
// مفتاح الكتابة الجيد (القيمة) {الحالة 1:/ * يقع من خلال */ case 2: dosomething () ؛ استراحة؛ الحالة 3: العودة صحيح ؛ الافتراضي: رمي خطأ جديد ("بعض الخطأ") ؛}إذا لم يحتوي عبارة SWEST على حالة افتراضية ، فيجب استبدال سطر من التعليقات.
// مفتاح الكتابة الجيد (القيمة) {الحالة 1:/ * يقع من خلال */ case 2: dosomething () ؛ استراحة؛ الحالة 3: العودة صحيح ؛ الافتراضي: // لا افتراضي}حاول البيان
يجب تنسيق بيانات فئة المحاولة على النحو التالي.
جرب {عبارات} catch (متغير) {عبارات} جرب {عبارات} catch (متغير) {عبارات} أخيرًا {عبارات}12. اترك أبيض
يمكن لإضافة خطوط فارغة من التعليمات البرمجية بين التعليمات البرمجية ذات الصلة بالمنطق تحسين قابلية قراءة الرمز.
يقتصر خطان فارغان على استخدامه في المواقف التالية:
• بين ملفات رمز المصدر المختلفة.
• بين تعريفات الفصل والواجهة.
خطوط فارغة خط واحد متوفرة فقط في الحالات التالية.
• بين الطرق.
• بين المتغير المحلي في الطريقة وبيان الخط الأول.
• قبل التعليقات المتعددة أو المفردة.
• يتم استخدام كتل التعليمات البرمجية المنطقية في الطريقة لتحسين قابلية قراءة الكود.
يجب استخدام المساحات في المواقف التالية.
• الحالة التي يجب أن تتبع فيها الكلمات الرئيسية بين الأقواس بواسطة المسافات.
• يجب ترك مساحة بعد فاصلة في قائمة المعلمات.
• يجب فصل المعاملات لجميع المشغلين الثنائيين باستثناء النقاط (.) عن طريق المسافات. لا ينبغي فصل معاملات مشغلات المونولوجات عن طريق الفراغات ، مثل علامة ناقص Unary ، زيادة (++) ، الانخفاض (-).
• يجب فصل تعبيرات البيان من خلال المسافات.
13. ما يجب تجنبه
• لا تقم بإنشاء كائنات جديدة باستخدام أنواع الغلاف الأصلية مثل String.
• تجنب استخدام eval ().
• تجنب استخدام البيانات. لم يعد هذا البيان موجودًا في الوضع الصارم وقد تتم إزالته أيضًا في معايير ECMAScript المستقبلية.
مكتوب في النهاية
لا يتم اتباع الأدلة أعلاه بالكامل أثناء عملية التطوير. يمكننا فقط رسم بعضهم لتحسين أسلوب الترميز الخاص بنا وجعل الكود القابل للقراءة وقابل للصيانة. فيما يتعلق بأسلوب الترميز ، لكل فريق خصائصه الخاصة. طالما أن الفريق متسق ، فمن الجيد التطور بكفاءة. بعض القواعد ليست شيئًا يجب أن نطيعه بطريقة ثابتة. على سبيل المثال ، من حيث المسافة البادئة ، غالبًا ما نستخدم مفتاح TAB أكثر ملاءمة ، لكن لا يمكننا ضمان أن TAB تمثل 4 مسافات في أي بيئة. من أجل الحفاظ على الاتساق في المسافة البادئة ، إذا تم استخدام مفتاح علامة التبويب ، فيجب استخدامه خلال العملية ؛ ولا يتعين علينا أيضًا استخدام "" "و" "، ومن الممكن أيضًا استخدامها" ، طالما أنك تحافظ على نمط ثابت. هناك العديد من مشكلات الأناقة المماثلة الأخرى ، كلها تعتمد على الاختيار الشخصي.
لا توجد قواعد مطلقة ، فقط مناسبة أم لا.