Що з усіма цими правилами кодування?

Я завжди підтримував ідею наявності правил кодування для розробників у компанії чи конкретному проекті. Особливо, якщо компанія розміром більше 10. Чим більше компанія, тим більша потреба. Я знаю, що багато людей не погоджуються, але я бачив проекти, які їх не мають, і код виглядає як тотальна катастрофа.

Справжня проблема, що випливає з цього, полягає в тому, як змусити тих, які не хочуть використовувати дужки, якщо заяви, або використовувати ту саму рядок з'єднання скрізь у коді чи будь-що інше, використовувати правила кодування, не змушуючи їх протиставляти Ідея?

Залучіть їх до вирішення проблеми, а не до правил боротьби. Я особисто віддаю перевагу ідеї "настанови стилів", "стандарти кодування" або щось подібне, сподіваючись, що це запобігає реакції на "коліні = погані" в коліні.

Але навіть якщо це так - я схильний вважати, що правила існують з якоїсь причини, і спосіб змусити людей з твердими головами обернутися - це зрозуміти, що, дотримуючись вказівок, вони допомагають полегшити код читати для всіх.

Іноді тиск однолітків є найкращим рішенням для цього.

У своїй роботі ми використовуємо всі три наступні рішення:

1) Прийміть перевірку стилю коду, наприклад, відмінний Checkstyle (для Java) або StyleCop (для C #). Це легко налаштовані засоби, які можуть автоматично виділити стиль кодування / відхилення правила. Це дає кожному нейтральну третю сторону визначити, що є, а що не прийнятно.

2) Прийміть шаблон коду переформатування автоматичного збереження (ось приклад за допомогою Eclipse) (та інший для Visual Studio), який автоматично відформатує ваш код при збереженні. Це чудово для того, щоб хтось міг кодувати те, що він бажає, але форматувати код однаково під час збереження / фіксації. Мені це дуже подобається, і наш код ніколи не був більш послідовним.

3) кодові огляди. Сподіваємось, ви все одно це робите, але одне, що слід виділити, це те, де правила / стилі кодування порушують умовність.

Окрім сказаного, важливо, щоб усі були на одному човні та домовилися стилів / правил, над якими вони працюють. Дайте зрозуміти, що ви не будете домовлятися з усіма про все, але попросіть зобов’язання колективу виконати те, що вирішує команда. Не забудьте час від часу переглядати стилі / правила, вибрані для врахування досвіду в реальному світі, використовуючи їх та перетворюючи команду.

Справжня проблема, що виникає з цього, полягає в тому, як зробити ті жорсткі голові, які не люблять використовувати дужки, якщо оператори, або використовувати ту саму рядок з'єднань скрізь у коді, або що завгодно,

Це вони "жорсткі голови", якщо вони не використовують дужки, чи це запит "жорсткого голови"?

Виберіть свої битви. Я сумніваюся, що це один із тих, кого варто вибрати. Мені б не сподобалося працювати де-небудь, що очікується десь поблизу такого рівня деталізації на "першу перевірку коду". Це червоний прапор, що команда не розуміє рефакторингу.

OO 101 : "Рефактор, коли виріб робить те, що йому потрібно зробити". Не раніше.

Досить складно сидіти на плечі кожного окремого розробника у великих командах, переконуючись, що вони ставлять дужки туди, куди ви думаєте, що їм слід йти - довіряйте мені на цьому;).

Якщо це щось, що ви насправді відчуваєте, заважає вашому розвитку, тоді вам знадобиться "воротар". Наприклад, не дозволяйте людям перевірятись без огляду коду. Попросіть технічного архітектора чи керівника команди переглянути код і відхилити його, поки вони не "виправлять" стиль коду. Вони незабаром від цього втомляться і пристосуються до правил, хоча, можливо, лише до тих пір, поки їх не перевіряють.

Звичайно, деякі компанії повністю відбирають пільги на реєстрацію молодших програмістів. Коли вони нарешті вивчають правила кодування компаній, тоді вони отримують привілей.

Я думаю, ви говорите про проблеми дуже різного рівня:

як змусити тих завзятих, які не люблять використовувати дужки, якщо заяви,

Це здебільшого проблема стилю / читабельності, якщо не існує явної проблеми пріоритетності оператора. Останнє не повинно бути дуже поширеним, і все-таки перевіряється одиницею, таким чином, легко виправити. Перший легко може перейти у Священну війну з невеликими вигодами, але серйозними негативними наслідками для моральної сили команди. Тож будьте обережні - використовуйте лише перевірені і перевірені правила, які були прийняті принаймні деякими командами / спільнотами та перевірені на роботу.

або використовувати однаковий рядок з'єднання скрізь у коді,

Якщо ви маєте на увазі Magic Constannts, це справді проблема технічного обслуговування (плюс потенційно безпека), і як такий IMHO будь-який досвідчений розробник зрозуміє і прийме, що це погана річ.

або що б там не було, використовувати правила кодування, не змушуючи їх протиставити ідею?

Ви не можете змусити людей погоджуватися з будь-якими правилами кодування - ваш єдиний шанс - дійти до загального розуміння та придбання від членів команди шляхом обговорення та (іноді запеклих) дебатів . Потрібно використовувати логічні та переконливі аргументи , показуючи значення, яке стоїть за кожним правилом, та пояснюючи, як слід слідувати за незручності коригування вбудованих звичок. З іншого боку, прагніть зробити перехід максимально простим , наприклад, запровадивши автоматичне форматування коду під час реєстрації відповідно до прийнятих правил.

Тим не менш, часом потрібно просто визнати, що люди мають різні думки , тому правила кодування, які кожен може прийняти, будуть певними в деяких аспектах. Прийміть це та зосередьтеся на областях, де ви можете покращити речі з меншими зусиллями.

Залучіть їх до встановлення правил. Зазвичай це допомагає спонукати людей слідувати за ними.

Це те, для чого призначений огляд коду. Рецензенти коду не повинні пропускати код, який не відповідає стандартам. Слідкуйте за тим, щоб не розслабляти правила термінових виправлень. Якщо потрібно кілька разів переробляти під тиском, щоб це зробити, виправите тих, хто не хоче виконувати свою роботу належним чином.

Один і той же рядок з'єднання скрізь? Рішенням цього є рефакторинг, поки ви не видалите всі дублювання. Кодери для копіювання та вставки повинні потрапити до в'язниці програміста. (Не смійся! Стів Баллмер - наглядач.)

Але справжньою проблемою тут є ваше дієслово «зробити» . Ви не можете змусити програмістів нічого робити, і якщо ви це робите, ви витрачаєте їх найціннішу характеристику: глибоку інтелектуальну приналежність, яка виникає внаслідок роботи над чимось, що вам цікаво.

Як я вирішував би це:

1. Наполягайте, щоб у команди був загальний стандарт кодування. Це може бути 5 рядків, але всі вони повинні погодитися.
2. Кожен раз, коли ви помічаєте аргумент, наполягайте на тому, що вони вирішують його разом і ставлять у стандарт кодування. Якщо ви помітили, як люди переформатують речі туди-сюди, розглядайте це як аргумент.
3. Щоразу, коли стандартний елемент узгоджений, подивіться, чи є інструмент, який очистить всю базу коду відразу.
4. Кожні пару місяців проходьте стандарт кодування і подивіться, які з них все-таки є правдивими та актуальними. Стандарт просто документує, що люди роблять. І немає сенсу зберігати в стандарті елементи, які стали очевидними.

Програмування - це командний спорт, або колективний художній твір. Те, про що люди домовляються, не має значення майже настільки, наскільки вони згодні, і добре підходять до нових домовленостей, якщо це необхідно.