الجزء 1. مقدمة...
الجزء 8. التسميةالجزء 9. التعليقات...
عند كتابة الكود ، نستخدم جميعًا قواعد تصميم الأكواد. في بعض الأحيان يتم اختراع القواعد الخاصة بهم ، وفي حالات أخرى ، يتم استخدام أدلة النمط الجاهزة. على الرغم من أن جميع مبرمجي C ++ يقرأون باللغة الإنجليزية بشكل أسهل من لغتهم الأم ، إلا أنه من الجيد الحصول على دليل في اللغة الإنجليزية.
هذه المقالة هي ترجمة لجزء من دليل أنماط Google بلغة C ++ إلى الروسية.
المقالة الأصلية (شوكة على جيثب) ،
ترجمة محدثة .
هذا هو الجزء التمهيدي من الدليل ، والذي يتناول الأسئلة العامة "لماذا؟"
أيضا ، بعد الترجمة سيكون هناك العديد من الإجابات على الأسئلة المحتملة.
دخول
C ++ هي إحدى لغات البرمجة الرئيسية المستخدمة في مشاريع Google مفتوحة المصدر ، ومن المعروف أن لغة C ++ هي لغة قوية جدًا. ومع ذلك ، فهي لغة معقدة ، وإذا تم استخدامها بشكل غير صحيح ، يمكن أن تكون مرتعًا للأخطاء ، مما يجعل من الصعب قراءة التعليمات البرمجية والحفاظ عليها.
الهدف من هذا الدليل هو إدارة تعقيد الشفرة عن طريق وصف بالتفصيل كيف يستحق (أو لا يستحق ذلك) كتابة كود C ++. قواعد هذا الدليل سوف تبسط إدارة الشفرة وزيادة إنتاجية المشفر.
النمط - اصطلاحات متبوعة برمز C ++ ، النمط أكثر من مجرد تنسيق ملف برمز.
معظم المشاريع المفتوحة المصدر التي طورتها جوجل تتبع هذا الدليل.
ملاحظة: هذا الدليل ليس تعليميًا لـ C ++: من المفترض أنك على دراية باللغة.
أهداف دليل الأنماط
لماذا هذه الوثيقة مطلوبة؟
هناك العديد من الأهداف الرئيسية لهذه الوثيقة ،
لماذا الداخلية ، والقواعد الفردية الأساسية. باستخدام هذه الأهداف ، يمكنك تجنب المناقشات الطويلة: لماذا القواعد ولماذا يجب اتباعها. إذا فهمت أهداف كل قاعدة ، فمن السهل عليك الموافقة عليها أو رفضها ، لتقييم البدائل عند تغيير القواعد لنفسك.
أهداف الإدارة هي كما يلي:
- يجب أن تكون القواعد تستحق التغيير.
- يجب أن تفوق فوائد استخدام نمط واحد استياء المهندسين في تذكر واستخدام القواعد.
- يتم تقييم الميزة مقارنةً بقاعدة الكود بدون تطبيق القواعد ، لذلك إذا كان الأشخاص لديك لا يطبقون القواعد ، فستكون الفائدة صغيرة جدًا.
- يشرح هذا المبدأ سبب عدم وجود بعض القواعد: على سبيل المثال ، ينتهك goto العديد من المبادئ ، لكنه غير مستخدم عملياً ، وبالتالي لا يصفها الدليل.
- الأمثل للقراءة ، وليس للكتابة
- سيتم استخدام قاعدة الكود الخاصة بنا (ومعظم المكونات الفردية منها) لفترة طويلة. لذلك ، سيتم قضاء وقت أطول بكثير في قراءة هذا الرمز أكثر من الكتابة.
- نحن نهتم بوضوح أن مهندسينا لديهم ليغو لقراءة وصيانة وتصحيح رمز. "ترك رمز التصحيح / التسجيل" هو أحد النتائج: عندما تعمل قطعة من التعليمات البرمجية "بغرابة" (على سبيل المثال ، عند نقل ملكية مؤشر) ، يمكن أن يكون وجود تلميحات نصية مفيدًا للغاية (يُظهر std :: unique_ptr بوضوح نقل الملكية).
- اكتب رمزًا مشابهًا للرمز الحالي
يتيح لك استخدام نمط واحد على قاعدة الشفرة التبديل إلى مشكلات أخرى أكثر أهمية.
أيضا ، نمط واحد يعزز الأتمتة. وبالطبع ، فإن التنسيق التلقائي للرمز (أو محاذاة #include ) يعمل بشكل صحيح إذا كان يلبي متطلبات الأداة المساعدة. في حالات أخرى ، يتم استخدام واحد فقط (الأنسب) من مجموعة القواعد ، وتسمح بعض المرونة في استخدام القواعد للناس بالمناقشة بشكل أقل. - اكتب رمزًا مشابهًا للرمز المستخدم في مجتمع C ++ (إن أمكن)
إن اتساق كودنا مع رمز C ++ الخاص بالمنظمات والمجتمعات الأخرى مفيد للغاية. إذا كانت ميزات C ++ القياسية أو التعابير المقبولة للغة تجعل برامج الكتابة أسهل ، فهذه مناسبة لاستخدامها. ومع ذلك ، في بعض الأحيان تكون المعايير والتعابير مناسبة للمهمة. في هذه الحالات (كما هو موضح أدناه) ، من المنطقي تقييد أو حظر استخدام بعض الميزات القياسية. في بعض الحالات ، يتم إنشاء الحل الخاص بك ، ولكن في بعض الأحيان يتم استخدام المكتبات الخارجية (بدلاً من مكتبة C ++ القياسية) وإعادة كتابتها وفقًا لمعيارك الخاص مكلفة للغاية. - تجنب الهياكل غير المتوقعة أو الخطرة.
C ++ لديه نهج غير واضح وحتى خطير. بعض أساليب الترميز تحد من استخدامها ، كما استخدامها ينطوي على مخاطر كبيرة لصحة الكود. - تجنب الإنشاءات التي يعتبرها مبرمج C ++ العادي صعبًا ويصعب دعمه
في C ++ ، هناك ميزات غير مرحب بها عمومًا بسبب تعقيد الكود.
ومع ذلك ، في التعليمات البرمجية المستخدمة بشكل متكرر ، يكون استخدام الإنشاءات الصعبة أكثر مبررًا بسبب الاستخدام المتكرر ، وستصبح الأجزاء الجديدة من الشفرة أكثر وضوحًا.
إذا كنت في شك ، استشر قائد المشروع.
هذا مهم جدا لقاعدة الكود لدينا ، كما يتغير مالكو الرمز وفريق الدعم مع مرور الوقت: حتى لو فهم الجميع الرمز الآن ، يمكن أن تتغير الأمور في غضون بضع سنوات. - النظر في نطاق الكود
مع وجود قاعدة بيانات لأكثر من 100 مليون خط وآلاف من المهندسين ، يمكن أن تكون الأخطاء والتسهيلات مكلفة. على سبيل المثال ، من المهم تجنب تناثر مساحة الاسم العالمية: يصعب تجنب تضارب الأسماء في قاعدة رمز كبيرة إذا تم إعلان كل شيء في مساحة الاسم العالمية. - تحسين حسب الحاجة
تحسين الأداء هو في بعض الأحيان أكثر أهمية من اتباع القواعد في الترميز.
الغرض من هذا المستند هو توفير التوجيه الأكثر قابلية للفهم مع قيود معقولة. كما هو الحال دائما ، لا أحد ألغى الحس السليم. باستخدام هذه المواصفات ، نريد إنشاء اتفاقيات لمجتمع Google بأكمله في C ++ ، وليس فقط للفرق الفردية أو الأشخاص. كن متشككا من التصاميم الماكرة أو غير العادية: عدم وجود قيود لا يكون دائما قرار. وإذا كنت لا تستطيع أن تقرر بنفسك ، فاسأل رئيسك.
نسخة C ++
الآن يجب أن تتوافق الشفرة مع C ++ 17 ، أي ميزات C ++ 2x غير مرغوب فيها. في المستقبل ، سيتم ضبط الدليل للإصدارات الأحدث من C ++.
لا تستخدم
ملحقات مخصصة .
فكر في التوافق مع البيئات الأخرى إذا كنت تنوي استخدام C ++ 14 و C ++ 17 في مشروعك.
ملاحظة: قد تؤدي الروابط إلى أقسام من الدليل لم تتم ترجمتها بعد.
بعض الإجابات / التعليقات:
- لماذا نقل؟
أنا شخصياً أشعر بالراحة أكثر مع القيادة الروسية. من الأفضل أيضًا مناقشة التغييرات في دليل الأنماط مع النص الروسي.
- لماذا جوجل؟ هل هناك أكثر (أو أقل) شعبية منها ...؟
الشركة معروفة تمامًا ، والقيادة ليست كبيرة جدًا (يمكنك ترجمتها دون جهد من جانب شخص واحد) ، فهي تلبي الوظائف المطلوبة - هذا الدليل في أسلوب
- لكن دليل جوجل يعلن استخدام عفا عليه الزمن (...) ، ورفض هذا مفيد (...)! لماذا؟
كما أفهمها ، هذه الوثيقة هي اقتراح. سوف تستخدم شيئًا ، وتغير شيئًا - هذا جائز. القيادة هي أساس جيد.