Чи вже потрібен стандарт кодування?


13

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

Чи є якісь аргументи для розробки стандарту кодування (у нас його немає, але я розглядав питання створення)?


Якщо ви все-таки вирішили впровадити стандарт кодування, подумайте про його виконання під час постійної інтеграції.
Лейф Карлсен

10
Якщо всі члени команди будуть зобов'язані використовувати один і той же IDE?
Кіт Томпсон

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

Не всі люди також використовують IDE, я використовую, наприклад, Acme.
дисоко

Відповіді:


33

Однак існує багато різних інструментів та IDE, які відформатують будь-який стандарт, який програміст віддає перевагу.

Удачі в цьому. З мого досвіду, існує невелика кількість інструментів (нуль!), Які можуть правильно переформатувати код з формату X у формат Y. Існує занадто багато речей, які заважають. Вкладки проти пробілів, багаторядкові оператори тощо. Просто подивіться на реалізацію GNU стандартних файлів бібліотеки C ++. Що ви можете зробити, це зробити ваш IDE - це завжди використовувати пробіли замість вкладок і просто не турбуватися переформатуванням закордонного коду. Тепер ваш код виглядає так, як вам подобається, а зовнішній код виглядає так, як його написав оригінальний автор.

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

Більші речі:

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

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

Стандарти кодування можуть мати непередбачувані наслідки. Приклад: Деякий дурень інженера проекту буде інтерпретувати «ніякої магії чисел правила» означає , що if (index == 0) {...}і for (ii = 0; ii < 3; ++ii) {...}повинна бути змінена if (ZERO == index) {}і for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}не смійтеся. Я бачив, як це відбувається. Сьогодні, коли я пишу стандарт кодування, це "правило магічних чисел", а не правило, яке протидіє такому глупству.

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


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

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

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

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

@GlenPeterson - Відступ / форматування є в моєму списку, або безпосередньо перед моїм списком: "IMO, стандарт кодування повинен визначати розумний набір прийнятних стилів відступу, але особливості залишати авторам пакета." І так, з правила "немає вкладок" є винятки. Наприклад, Makefiles.
Девід Хаммен

60

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

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


1
Хороша відповідь, я розширив мої знання гарним поясненням, що стосується речей, про які я не думав. +1
SomeKittens

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

3
Якщо ви вважаєте, що ця відповідь хороша і відповідає на ваше запитання, просто позначте її як таку.
martani

3
Не кажучи вже про те, що масове переформатування може викликати головні болі, коли ви кинете туди ще один хороший стандарт: контроль джерел.
Меттью Шарлі

1
@MatthewScharley, як правило, ви натискаєте змінений код через формат, а потім здійснюєте (після, можливо, останнього тестового запуску, щоб переконатися, що формат нічого не зламав), тому лише форматизований код потрапляє на репо
ретчет-фрік

13

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

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


4
Відмінності! Я не думав про це.
SomeKittens

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

5

Короткий відповідь: Так, це відображає якість .

Що це таке і навіщо нам це потрібно?

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

введіть тут опис зображення

Добре, кожен розробник знає, що умови кодування є хорошими. Але звідки беруться стандарти?

Це здебільшого диктує продавець, якому належить товар. Кожен розробник може вибрати один з багатьох галузевих стандартів кодування. Деякі компанії Microsoft, Oracle і Sun Microsystems пропонують рекомендації.

Чи є якісь аргументи для розробки стандарту кодування (у нас його немає, але я розглядав питання створення)?

Так, є галузеві стандарти, які рекомендується використовувати. Однак кожен стандарт кодування є специфічним для платформи розробки. Таким чином, стандарти кодування є переважно мовними. Наприклад, Java має інший стандарт, ніж .NET. Наприклад, C # .NET використовує ці стандарти у цій довідці .

Загальні стандарти

Загальні стандарти не залежать від будь-якої мови програмування. На додаток до пропонованих постачальниками стандартів, так само згаданих галузевих стандартів кодування, існують різні позначення програмування, такі як Угорська нотація або CamelCase . Я думаю, що стандарти кодування Microsoft .NET спочатку базувалися на позначеннях CamelCase.

Стандарти та рекомендації щодо кодування команди

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


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

я ще не закінчив свою відповідь
Юсубов

Це While Notмає бути повністю Do Until.
Ри-

2

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

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

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

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

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

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


Штраф мені - ще одна річ, на що не витрачати час, особливо якщо всі розробники мають ліцензію Resharper і fxcop / stylecop працює на сервері збірки.
StuartLC

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

@Andrew Цей досвід може не застосовуватися і може просто пов'язувати вас з великою кількістю ідей, які не
Дуг Т.

1
+1 для задушення інновацій, контролю підмножини, загальних найкращих практик та політики. Навчайте, не регулюйте!
kirk.burleson

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

1

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

Див.: Запропоновані Федеральним управлінням авіації стандарти C та C ++ кодування

Потрібно сказати більше.

Примітка: я не зміг знайти фактичний стандарт у ФАА в Інтернеті, але я його бачив.


Це прототипний стандарт поганого кодування. Це занадто довго, це викликає релігійні питання, а головне - це суперечить сучасним програмуванням на C ++. Наприклад, він виключає POD (звичайні старі дані), а його правила щодо винятків коливаються від поганих до архаїчних. Погано: спроба зловити std :: bad_alloc виявляється дуже поганою ідеєю. Archaic: Ідея Java щодо визначення всіх винятків, які можуть бути кинуті, і вилучення всіх винятків, викинутих викликаними функціями, просто не працює в C ++. Набагато краще - написати безпечний для винятків код на основі концепцій гарантій виключення Девіда Абрахамса.
Девід Хаммен

1

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

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

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


1

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.