Чи може бути занадто багато однаковості в стандартах кодування?

12

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

Наприклад, написання ifвисловлювань у декількох рядках проти одного рядка, використовуючи ??оператор c # null-coalescing замість сказати == null, кількість пробілів для відступів тощо

Мені здається, це починає все більше перетворюватися на особистий вибір стилю, і не потрібно бути однаковим у команді чи компанії. Те, що одна людина думає, читає чіткіше, інше не може. Чи є якась цінність цієї "додаткової" рівномірності?

programming-practices team coding-standards

— Gratzy
джерело

2

Привіт Gratzy, Programmers.SE - це не дискусійна дошка ; ми тут, щоб вирішити реальні проблеми, з якими ти можеш стикатися. Чи є у вас актуальна проблема, яку ви намагаєтеся вирішити? Якщо так, чи можете ви переформулювати своє запитання, щоб відповісти конструктивними та не виходити з підводних каменів?

1

@Gratzy кажучи іншим способом, враховуючи ситуацію, з якою ви особисто стикаєтесь, які були б критерії правильної відповіді?

2

@ Марк Трапп відповідно до FAQ - це критерії для запитання. Усі суб'єктивні питання повинні бути конструктивними. Як ми це визначимо? Конструктивні суб'єктивні запитання ... 1. надихайте на відповіді, що пояснюють "чому" та "як". 2. мають тенденцію мати довгі, не короткі відповіді. 3. мати конструктивний, справедливий та неупереджений тон. 4. запропонувати поділитися досвідом щодо думок. 5. наполягайте, щоб думка була підкріплена фактами та посиланнями. 6. є більш ніж просто безглуздою соціальною забавою. Я вважаю, що моє питання принаймні стосується перших 4

— Gratzy

2

@Gratzy також із FAQ: "Ви повинні задавати лише практичні, відповідальні запитання, засновані на актуальних проблемах, з якими ви стикаєтеся. Чатливі, відкриті запитання зменшують корисність нашого сайту та відштовхують інші питання від головної сторінки".

2

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

— Gratzy

16

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

Найкраще просто встановити базовий стиль для найважливіших речей (стандарти називання та написання великої літери, відступ, розміщення нових рядків і дужок тощо), встановити рекомендації щодо менш важливих речей (якщо формат заяви, інший пробіл навколо дужок тощо). , а потім не турбуйтеся про інше.

— Ніколь
джерело

1

Я там був

+1, сказав, що я маю на увазі, але краще!

— FrustratedWithFormsDesigner

@Pierre - це те, чому ти зараз позаштатний? :)

— Ніколь

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

7

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

Більшість IDE можуть застосовувати стилі сьогодні, тому за потреби ви можете розповсюджувати (як частину вихідного коду проекту) файл налаштувань IDE, який визначає обраний стиль кодування, і всі бажаючі встановлюють його та використовують його для форматування коду, який вони пишуть . Гадаю, що є навіть способи переформатувати / стилізувати код під час реєстрації (хоча мені ще не довелося цього досліджувати).

— FrustratedWithFormsDesigner
джерело

Так, ти, певно, десь там міг би наклеїти сценарій мурашок.

— Майкл К

1

Принаймні, IntelliJ має можливість переформатувати код перед реєстрацією.

— Ніколь

3

Я бачив один із випадків нерівномірності - мати єдиний стандарт, який застосовується до всіх мов програмування незалежно від відповідності:

Дестимулювання gotoнавіть в таких мовах , як C без try... catch.
Використання InitialCapsімен (як у Microsoft MFC та C #) у JavaScript, де стандартна бібліотека initialLowerCase.

— dan04
джерело

2

Я не думаю, що існує таке поняття, як занадто велика однаковість. Однак я часто вважаю, що в стандартах кодування занадто багато СПЕЦИФІЧНОСТІ. Переваги кожного, хто ставить початкову дужку окремою лінією, в кращому випадку сумнівні і не переважають витрачений на час час, сперечаючись про це або фіксуючи косметичні проблеми в коді.

— JohnFx
джерело

2

@Tungano Я не міг погодитися більше. Парадокс стандартів кодування полягає в тому, що їх варто мати, але сперечатися з ними не варто.

— Чарльз Е. Грант

3

Я не бачу, як примушення певного стилю до горла програміста допоможе вам уникнути цих аргументів. Насправді я б заперечував, що змусити програміста адаптуватися до стилю, який їм не подобається НАДКЛЮЧИТИ ці аргументи або, принаймні, обурюватися.

— JohnFx

1

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

— Чарльз Е. Грант

1

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

— JohnFx

1

Я працюю з кодом нашої німецької команди, парою проектів OSS та деяким стародавнім кодом, який ми маємо, а також з нашими поточними речами. Деякі - це C, деякі C ++, деякі C #. Тому мені доводиться постійно працювати з декількома різними стилями коду. Виконуючи це, ви усвідомлюєте, наскільки дрібні стильові рекомендації, які отримують мандат у стандартах. Якщо я можу переключитися з одного на інший проект, я можу впоратися з тим, хто розміщує їх {} в різних місцях. Ось чому я вважаю, що єдиний стандарт, який вартий прокляття, - це правило з 1 правилом: "узгодженість у кожному проекті".

— gbjbaanb

2

У мене були б два аргументи про однаковість:

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

— Дж. Б. Кінг
джерело