Я прийму суперечливу думку і скажу, що ні, вам не потрібен стандарт кодування . Або, як ви кажете, правила - це правила, що відповідають вимогам ІДЕ, загальні найкращі практики, яких слід дотримуватися кожному в кожній компанії, або це виклики у судовому порядку за командою, які повинно робити більш ніж одна людина у дієздатній команді через парне програмування або огляди коду.
Такі речі, як ми повинні називати цю змінну? Які мовні особливості ми повинні використовувати? Чи слід уникати? Яке тестування найкраще? Вони найкраще залишатись без відповіді, поки ми не зіткнемося з вузько визначеною проблемою, над якою зараз працюємо .
Викристалізовані з цих хвилинних рішень, можуть виникати неофіційні стандарти / зразки в колективах, виходячи з перетину поточної проблемної області та використовуваних технологій. Кодифікувавши ці засоби, ми вважаємо, що такі речі, як стандарт іменування, відповідна підмножина мови тощо, що використовується в цих проектах, засновані на сотнях мікро-рішень, і неофіційно прийняті цими командами повинні керувати кожним проектом, що рухається вперед.
В принципі це звучить як чудова річ, але насправді це просто стає магнітом для політики. Які інструменти ми можемо змусити всіх використати? Що я хочу змусити інших людей уникати? Якби всі погодилися з цими питаннями, нам би не потрібен стандарт. Ми просто зробимо це. На мій досвід стандарти виходять із бажання однією підмножиною розробників здійснювати контроль над іншим підмножиною. Зазвичай такий тип політики та технологічна поліція, яка слідує за нею, лише пригнічують інновації, а не надають настанови.
Якщо ви хочете справжніх вказівок , замість того, щоб читати стандарт із купою непотрібних правил, ідіть, знайдіть здібних членів вашої команди та запитайте їх, що вони думають. Чим вони спалили? Як вони пропонують вам написати код? Ви отримаєте різноманітні корисні відповіді з великим цінним досвідом, щоб підкріпити це. Ви побачите багато перехрестя на основі спільного досвіду. Замість монокультури, яку застосовує стандарт, ви також побачите багато різноманіття, яке може допомогти вам побачити безліч дійсних способів вирішення проблем.
І коли хтось каже вам не робити щось причиною правила в "стандарті", але не має досвіду чи розумного резервного копіювання їхніх претензій, ігноруйте їх. Тут стандарт нікому не служив і не робив когось кращим розробником.