دليل Google لأسلوب Rust يفرّق بين كود المكتبات وكود التطبيقات في إلزام قواعده

لدى Google دليل لأسلوب كتابة Rust منشور على موقع أدلتها الرسمي، وقد عاد إلى النقاش في 21 أكتوبر 2026 بعد ظهوره على Hacker News. ولا تحمل الصفحة تاريخ نشر أو تعديل. ويطبَّق الدليل على قاعدة google3 وعلى Android وChromeOS وFuchsia وChrome، وفيه ملاحظات خاصة لكل قاعدة كود، ويذكر أن Android وChromium يعتزمان البدء في تطبيقه بدرجات صرامة مختلفة.

وأهم ما فيه لا يخص Rust وحدها. فالدليل يفرّق بين نوعين من الكود ويكتب القاعدة نفسها بصيغتين. قواعد تصميم الـ API ملزمة لكود المكتبات، أما لكود التطبيقات فهي “توصية قوية” فقط، مع نص صريح على أن كود التطبيق يجب أن يفضّل البساطة على إعادة الاستخدام.

ويحسم هذا التفريق نوعًا كاملًا من الخلاف في مراجعة الكود. فكثير من النقاش في الـ review لا يدور حول الصواب والخطأ، بل حول طرفين يطبّقان قاعدة واحدة على كود له استخدامان مختلفان. وحين يكون مكتوبًا من يُلزَم بماذا، لا تتحول كل مراجعة إلى تفاوض جديد.

وفي الدليل قواعد أخرى تصلح لأي لغة. منها استخدام enum بدل قيمة boolean حين لا يكون معنى الوسيط واضحًا من اسم الدالة. ومنها أن الماكرو آخر حل لا أوله، بترتيب مكتوب: الدوال والأنواع والـ traits أولًا، ثم macro_rules!، ثم توليد الكود، وأخيرًا proc_macro. ومنها تجنب Rc وArc إلا إذا كان البديل معقدًا بشكل غير معقول، واستخدام #[non_exhaustive] للـ enums العامة التي تعبر حدود الفرق. ويسمح الدليل بتخطي الـ formatter للمحاذاة اليدوية والكود المولَّد فقط، وينص على أن التنسيق لا يُتخطى لأسباب أسلوب شخصي.

ولـ Chromium قواعد خاصة إضافية، منها ألا يُستخدم async/await ولا threads المكتبة القياسية، وألا يُستخدم catch_unwind لأنه يعمل بإعداد panic=abort.

وتترك فرق كثيرة قواعد المراجعة اتفاقًا شفهيًا، والدليل مثال على ما يتغير حين تُكتب هذه القواعد مرة واحدة ويُحدَّد نطاق كل منها.