Поводження зі стандартами кодування на роботі (я не начальник)

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

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

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

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

Дякую всім за ваш час.

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

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

У нас із колегою була схожа проблема з нашою командою, коли ми вперше приєдналися (я вперше приєднався до команди, він приєднався приблизно через рік). Реальних стандартів коду не було. Ми - магазин MS, і навіть стандарти кодування MS не використовувались. Ми вирішили навести приклад. Ми сіли разом і склали документ, який мав усі наші стандарти: стандарти IDE, стандарти іменування, все, що ми могли придумати. Тоді ми з нами домовились чітко слідувати стандарту. Я надіслав електронну пошту команді (від нас обох) і повідомив їх, що ми виявили недолік, і ми збираємося вирішити цей недолік своїм документом. Ми запросили критику, ідеї, коментарі, думки. Ми отримали дуже мало способів зворотного зв'язку і лише трохи відштовхуємось. Ми з ним негайно почали використовувати стандарти, і коли ми залучили молодших розробників до наших проектів, ми ознайомили їх зі стандартом, і вони почали його використовувати. У нас є кілька приводів, які спочатку неохоче, але повільно почали використовувати стандарт для багатьох справ.

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

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

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

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

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

Чи можете ви показати деякі докази часу, який ви витратили через проблеми, які це викликає?

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

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

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

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

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

Що стосується стандартів кодування: я буду брати участь у роботі майже з усіма іншими, кажучи, що стандарти кодування - це "хороша річ" (проти жодних стандартів).

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

Просте рішення: Надайте розробникам обмежений набір варіантів дужок та відступів, але продиктуйте, що стиль дужки та відступ мають бути узгодженими для кожного модуля. (Ви хочете, щоб foo.h і foo.cpp дотримувалися того самого стилю, чи не так?) Обслуговувачі повинні адаптуватися до існуючого стилю; вони не можуть переписати модуль відповідно до їх примхливого стилю. Кілька стилів в модулі просто заплутані і є ознакою неохайності. Коли я бачу цю нісенітницю, це змушує мене замислитися, що ще не так.

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

Все, що було сказано, я думаю, що у вас може виникнути глибша проблема у вашому проекті. Ви згадали про проблеми зі злиттям. Якщо вам доведеться зробити багато об'єднань, це може бути ознакою поганого розподілу проекту. Так само, як занадто багато кухарів псують бульйон, занадто багато програмістів, що працюють на одному файлі, псують проект. Чому кожен з Джо, Сьюзі, і ви торкаєтесь foo.cpp?

Це одна з областей, в якій проводяться деякі дослідження. В основному головне питання - чи ви робите огляд коду. Огляди коду, без сумніву, є найбільш ефективним засобом поліпшення якості коду. (Джерело: Інститут інженерії програмного забезпечення, КМУ). Це, звичайно, більш ефективно, ніж додатковий тестер.

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

Оскільки вже є «кілька інших», які з вами на цьому, я б запропонував імпровізовану зустріч. Запросіть усіх чортів, пройдіть короткий час і з’ясуйте, що щодня турбує вас і ваших колег. Спочатку не намагайтеся знайти конкретні рішення, просто з’ясуйте, що потребує змін у тому, як ви зараз пишете код.

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

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

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

Є деякі речі, які боляче. Найбільш болючим є IDE, який автоматично переформатує код у поєднанні з розробниками, які встановлюють свої IDE різними способами. Кожен раз, коли ви порівнюєте код, у вас є сто змін після того, як хтось з різними налаштуваннями редагував код. Це неприпустимо. Тут потрібно збити голову всім разом, домовитись про набір налаштувань та відхилити будь-які перевірки будь-хто, хто використовує різні налаштування. Якщо я зміню один рядок коду, розмінник повинен показувати змінений один рядок коду, а не сотні.

Все інше або нешкідливе, або є кращі способи зробити те, в чому можуть бути переконані інші. Тут має бути таке правило: Не возитися з кодом інших людей, якщо ви дійсно не вдосконалите його. І поєднання стилю A і стилю B завжди гірше, ніж і стиль A, або стиль B.

Переконайтеся, що ви дотримуєтеся найкращої практики. Що відрізняється від мови. Але там вам не потрібні стандарти (які, можливо, написав хтось добронамерений, але насправді не той, хто знає), але кожен повинен спробувати навести хороші приклади.

Однозначно уникайте боротьби за владу. Немає нічого гіршого, ніж якийсь маленький Гітлер у вашій команді намагається примусити всіх до його волі. І це, на жаль, хлопець, який добровільно напише ваші стандарти кодування :-(

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

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

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

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

конфлікти, коли я зливаюся, тому що хтось використовував їх IDE для автоматичного форматування, і вони використовують інший символ для відступу, ніж я

звучить так, що це ваша проблема, не форматування, а переформатування. Це величезна проблема для СКМ, і порада проста: не робіть цього. Тож наступного разу, коли хтось переформатує всі пробіли на вкладки або переробляє фігурні дужки у відповідний їм стиль, вам потрібно ляпати їх. Змусити їх зробити злиття замість цього; стоїть над ними, не дивлячись на марну трату часу, яку викликала їх бездумність.

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

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

Що стосується Вашого конкретного питання, Ваша найкраща ставка, ймовірно, починається з пропозиції Джоеля та веде за прикладом. Зберіть 1 або 2 програмістів, котрі про це дбають, домовтеся, і вам доведеться трохи накладати сили на ледачих.

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

Не спробуйте цього!

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

Якщо ваші колеги не лишиться (!!), ви можете отримати стандарт кодування.

Очевидно, що це стратегія високого ризику ... :-)