Зв'язок з колегами, які не мають послідовного стилю кодування?

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

• Суміш різних угод про іменах і назвах ( underscore_styleі , camelCaseі , UpperCamelі CAPSвсі застосовувані більш-менш випадковим чином в різні змінні в одній і тій же функції)
• Химерні та непослідовні інтервали, наприклад Functioncall (arg1 ,arg2,arg3 );
• Багато неправильно написаних слів у коментарях та назвах змінних

У нас є гарна система перегляду коду, де я працюю, тому ми все одно шукаємо і виправляємо найгірші речі. Однак, надіслати огляд коду, який складається з 50 рядків "Додати пробіл, правильно". Написати "ітаратор" правильно. Змініть цю велику літери і т.д. ".

Як би ви закликали цю людину бути більш уважним та послідовним до таких деталей?

Погодьтеся на умові кодування

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

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

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

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

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

У нас є гарна система перегляду коду, де я працюю, тому ми все одно шукаємо і виправляємо найгірші речі. Однак, надіслати огляд коду, який складається з 50 рядків "Додати пробіл, правильно". Написати "ітаратор" правильно. Змініть цю велику літери і т.д. ".

Я б сам змінив його, а потім додав би ввічливий коментар до коду.

це передбачає, що вже існує посібник зі стилів, оскільки зазначене питання:

У нас гарна система перегляду коду

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

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

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

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

Один з моїх колег пише html таким чином, що це змушує мою шкіру повзати. Уявіть, що мій html гарний і структурований з двома космічними відступами, зірваними на шматки, доданими тегами, доданими до кінця шахти, які закінчуються на тій же лінії або на наступному, як якийсь п’яний, якому потрібно кинути руку, щоб ви стояли стоячи. Нові лінії рідко з відступом, але якщо вони є, я впевнений, що в якійсь частині галактики є якась хаотична чорна діра, яка випльовує значення ірраціональних температур таким чином, що якимось цифрами відображається кількість пробілів або вкладок, що використовуються в такому відступі. від цієї жінки. Якщо мені пощастить, я побачу вхідний тег, закритий " </input>". Загальний кошмар, який ви можете зрозуміти.

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

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

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

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

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

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

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

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

Ось речі, які мають стимулювати:

1. Огляди коду будуть виснажливими та довшими, ніж потрібно.
2. Код буде відхилятися частіше.
3. Розклади не будуть дотримані.

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

Мені б сподобатися запропонувати приватний чат і дізнатись, чи зможете ви знайти першопричину:

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

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

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

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

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

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

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

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

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

У нас є тест JUnit, який шукає проблеми форматування. Він працює як частина збірки. Я постійно отримую біт, опускаючи пробіл між дужками "if" ("час"), "" для ("" "" "" ")" для ". Однак наш код послідовно відформатований.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

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

Якщо ви використовуєте Eclipse, тоді ввімкніть Збереження дій для редакторів Java та скажіть усім, щоб вони його використовували. Це виправляє проблеми із форматуванням при кожному збереженні, але не виправляє неправильну букву. Це може бути дуже корисно, хоча!

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

ЛОЛ. Ви абсолютно ненавидите мій код. Я не можу заклинати, щоб врятувати своє життя, і мені все одно.

Але я знаю, що деякі люди насправді дбають про ці речі.

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

Зазвичай технічно правильний, розумно структурований і може бути навіть алгоритмічно елегантним

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

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

Моє рішення при роботі з аутсорсинговими ресурсами, які не давали &% $ # щодо форматування (або легко запобігаються помилки в цьому питанні), полягало в тому, щоб сервер збірки виконував це. Я створив CI-серверну роботу, що проводився щовечора, перевіряючи код, запускав Jalopy і findbugs, а потім перевіряв код назад. Як тільки інша команда дізналася, що використання стандартних конвенцій коду ускладнить їх роботу, вони почали використовувати їх IDE для підтримки стандартного формату.