Я ненавиджу один із наших стандартів кодування, і це мене зводить з розуму, як це обробити? [зачинено]

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

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

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

Стандарт - це стандарт, який відкривається фігурно-фігурною дужкою на спеціальній лінії:

somefunction()
{
    //...
}

Замість * явно перевершеного * (зверніть увагу на жартома / розчарований тон):

somefunction() {
    //...
}

Мої особисті аргументи проти стандарту:

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

Їх аргументи (і мій спосіб внутрішнього переказу на них):

• Простіше читати, оскільки ви можете бачити, де блоки починаються і закінчуються відразу : я не можу зрозуміти це, чим хороший блок, якщо ви не знаєте, чим він належить, тож вам доведеться читати назад.
• Я використовував це в Microsoft IDE, і мені сподобалось : Ага ... нормально?
• Це в стандарті : * планки *

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

Якщо ви хочете подолати це - була цитата Торвальда:

Погані програмісти турбуються про код. Хороші програмісти турбуються про структуру даних та їх зв’язки.

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

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

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

Що мені допомогло пройти через це:

1. Зрозумів, що для одного стилю є реальні переваги (незалежно від того, що це таке). Або принаймні купа людей так думають .
2. Точно те, що ви тільки що зробили, випишіть, чому він почувається не так, щоб ви могли добре поставити аргумент у майбутньому.
3. Використовуйте інструмент для стилізації заради бога , це збереже ваш розум. Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , і т.д. ... навіть Visual Studio зробить це за вас .
4. Відкиньте цей проект і будьте готові до наступного, коли зможете встановити стандарти.

Перевага однієї конвенції над іншою є * явно довільною * .

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

Об'єктивний аргумент читабельності на користь * послідовності * у всій базі коду.

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

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

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

"Явно вищий", про який ви говорите, - це такий тип вищого, про який говорять люди, коли вони говорять про речі, "до яких звикли".

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

Отже, коротше: розбирайтеся з цим.

Цей конкретний предмет є релігійною війною між тими, хто віддає перевагу одному стилю над іншим. Дуже мало людей амбівалентні ...

Зрештою, ні право, і жодне не є неправильним.

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

Я єдиний, хто бореться з висловлюваною позицією проти певного стандарту?

Коротка відповідь - «Ні», ви не єдиний. Але є більш важливі речі, про які слід хвилюватись. Навіть у стандартах, до яких можна вплинути, завжди буде компроміс - засвідчуйте деякі аспекти, які ввійшли в C99 та C12, які не мають для мене сенсу.

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

як ти пережив це?

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

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

Я думаю, що вам просто потрібно продовжувати це. Я спробую висловити ваші нотатки своєю власною думкою:

• Код Блатса

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

• Важко вводити

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

• Важче читати

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

• Використовується людьми, які походять з MS IDE

  А-а ..... гаразд?

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

Я єдиний, хто бореться з висловлюваною позицією проти певного стандарту?

Звичайно, ні. Зустрічі для визначення стандартів кодування жахливі! Вони затягуються годинами, і учасники особисто вкладаються в отримання власного улюбленого (і незмінно помилкового, за винятком моїх) ідіосинкрасій, закріплених у стандарті. До кінця результатом ніхто не задоволений. Якщо що-небудь може бути гіршим, ніж зустріч стандартів кодування, це офіційні зустрічі з перегляду коду за кілька місяців, які слідують за визначенням стандарту: деякі намагаються прийняти стандарт, а інші (навмисно чи ні) ігнорують його, і ви отримуєте години зворотного зв’язку на кшталт: У рядках 132, 142, 145, 181, 195 та 221 SillyFileConverter.cpp ви ставите вступну дужку на ту саму лінію, коли стандарт кодування чітко говорить, що вона повинна бути в наступному рядку!

як ти пережив це?

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

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

З такою штукою я пам’ятаю Гуллівера в Лілліпуті. Ліліпути ведуть війну, в якій закінчуються відкриття вареного яйця. (Первісний великий ендіанський, маленький ендіанський бій).

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

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

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

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

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

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

У будь-якому випадку, режим Glasses не обробляє розміщення брекетів, ви, ймовірно, не використовуєте Emacs і не читаєте код виключно у своєму редакторі :-(
Але останній пункт - це також можливість - якщо ви читаєте код більшу частину часу в окремим інструментом ви можете зламати це для перетворення стилів, не турбуючись про зворотне переформатування шуму - адже це лише для читання! Зокрема, якщо ви читаєте код у деяких веб-інтерфейсах, використовуйте Greasemonkey.

Ось кілька простих ідей для легкого пом'якшення наслідків:

• Виберіть ширший, але не такий високий шрифт, щоб відновити втрачені лінії екрана.

  • Використовуйте на весь екран частіше, якщо вони доступні.

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

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

• Повторно "важче набрати": отримайте справжній редактор, налаштуйте його, щоб автоматично відкривати новий рядок при натисканні {.

Живи з цим.

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

Для такого типу кодування я б підбирав послідовність у кодовій базі та читабельність щодо будь-якого конкретного (навіть добре обґрунтованого) "релігійного" підходу будь-якого дня.

Думаючи про це як про демократичне рішення більшості членів команди про не дуже важливу проблему, можливо, допоможе вам подолати її.

Це стандарт:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

Більшість хтось каже: "його стандарт" - це принцип "п'яти мавп".

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