Чи стиль кодування в організаціях необов’язковий?

Цей документ у стилі програмування має загальне правило, яке говорить:

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

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

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

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

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

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

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

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

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

Ці заперечення можуть бути помилковими, зауважте, але (і це дуже ВЕЛИКОЕ, АЛЕ) вони також можуть вказувати на те, що певне правило є неправильним - або в цілому, або в конкретному контексті проекту (один із прикладів невідповідності правил - це вимога надати детальний вхід критичного коду продуктивності).

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

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

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

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

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

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

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

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

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

Дозволити людям ігнорувати стилі кодування через особисті переваги - погана ідея.

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

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

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

Тим не менш, доцільна деяка гнучкість у дотриманні настанов щодо стилів:

• Слов'янське дотримання інструкцій може перешкодити найкращому способу написання певного коду . Розробники повинні мати можливість ігнорувати настанови та вважати, що те, що вони зробили, є найкращим, найчитабельнішим способом досягти чогось у цьому випадку.
• Робота зі застарілим кодом може вимагати гнучкості. Напевно, не дуже корисно використовувати свій час, щоб переосмислити велику існуючу кодову базу. Якщо ви перепишете певний розділ значно, ви можете переформатувати його у бажаний стиль. Однак якщо ви просто внесете невелику зміну, можливо, буде краще використовувати існуючий стиль коду.
• Мислити про кожне невелике порушення керівництва зі стилем - це не дуже корисний час. Огляд коду - хороший час, щоб виділити будь-який код, який суттєво не відповідає стилю команди. Однак лов і виправлення малих стильових «помилок», швидше за все, стане напруженою роботою, зосередженою на неправильній справі. Звичайно, не вдалося переглянути код, якщо стиль явно проігнорували. Але мені не подобається ідея запускати аналізатор і вказувати на будь-які неправильно поставлені дужки чи відступи, не маючи на увазі, якщо хтось вийшов з ладу на цій основі.

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

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

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

Пам’ятайте, все, і наголошую, ВСЕ, від програмування OO до функціональних парадигм, до різних моделей одночасності, існує єдиною причиною, що допомагає людям вирішувати складність.

Будь-який дурень може написати код, який комп'ютер може зрозуміти. Хороші програмісти пишуть код, який люди можуть зрозуміти. - Мартін Фаулер, 2008

Чи стиль кодування в організаціях необов’язковий?

Організації вирішили мати стилі кодування - не потрібно бути в першу чергу.

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

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

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

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

Це залежить.

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

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

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

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

З кожного правила є винятки. Дайте людям "якусь" кімнату для вивірки. Чим менше кожен бере участь у прийнятті правил стилю кодування (Ласкаво просимо нового хлопця.), Тим більше вони схильні бажати відбиватися. Багато речей чорно-білі, але деякі відкриті для інтерпретації.

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

Так, настане час, коли документ у стилі кодування не має сенсу використовувати, а професійним та дорослим розробникам слід дозволити знати різницю.

Виходячи з ваших змін, ви прагнете досягти правильної мети.

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

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

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

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

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

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

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

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

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

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

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

Більш конкретно, оскільки ви несете відповідальність за встановлення настанов щодо стилю кодування (це моє припущення, оскільки ви є автором документа), ви приймаєте рішення про те, що є необов’язковим чи ні, і в якій мірі ви дозволите гнучкість в особистому стилі вашого команда. Ви отримаєте зворотний зв'язок там, де потрібно. Але як тільки рекомендації будуть встановлені, дотримуйтесь їх.

Таким чином, ви можете примирити два здаються протиріччя, як це:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( Відмова: Я повністю написав цю реалізацію, is_base_ofщоб вирішити найголовнішу задачу, і заробляв кожний шматочок пекла, який я отримав за це від старших розробників. Я кажу, що це того варте. Я все одно отримую чудовий міхур сміху щоразу, коли я подивіться на те, як такі клини, як 7 непов'язаних частин специфікації C ++ разом, щоб зробити щось дивовижне. Візьміть це, ви, старші розробники! Це те, що ви отримуєте за заборону boostна цей конкретний проект! )

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

Цілком розумно вимагати від усіх розробників звички застосовувати форматер до новоствореного розділу коду.

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

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

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

Актуальне рішення (не лише філософія)

Дозволити коментарям коду заміняти зв'язки та скласти списки цих коментарів, якщо вам це подобається (як це робиться з коментарями todo часто)

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