Наскільки важливі рекомендації щодо форматування коду? [зачинено]

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

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

Попросити всіх на 100% дотримуватися однієї і тієї ж стандартної інструкції щодо форматування коду - це як попросити всіх співпрацювати окремо над написанням паперу на 100 сторінок з тим же стилем написання.

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

Я думаю, ви торкнулися найважливіших моментів:

1. Це настанова
2. Читабельність

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

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

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

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

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

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

Він ніколи не був прийнятий.

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

Зі свого боку, я дотримуюся загальноприйнятих вказівок від Microsoft і емулюю загальновживані стилі інших (Javascript та jQuery відформатовані по-різному від C #, хоча вони обидві кучеряві мови). Я також час від часу порушую правила, коли це зробить код читабельнішим.

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

Те, що можна зрозуміти для однієї людини, буде не для всіх людей.

Якщо ви не використовуєте цей тип IDE, отримайте його. Навіть думати про це більше 10 хвилин - це марно витрачати ресурси ІМХО.

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

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

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

Один набір керівних принципів, які я використовую під час розробки або оновлення наших форматів кодування, - це гештальт Принципи групування - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

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

if(true)
{
}

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

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

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

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

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

Правила допомагають покращити якість коду:

• з точки зору письменника: багато правил спрямовані на зменшення впровадження помилок. Наприклад, правило, яке вказує на те, що if()або за for(;;)конструкціями повинен дотримуватися блок, а не одна інструкція, робить намір початкового кодера явним і допомагає наступним кодерам підтримувати це.

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

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

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

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