Чи повинна моя команда використовувати якийсь загальний добре сприйнятий стандарт кодування як свою власну основу?

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

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

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

Це звичайна практика? Чи вірите ви, що це гарна ідея? Якщо так, то що було б розумним «базовим» стандартом кодування (не кажіть мені, що найкраще, я не хочу тут починати релігійний конфлікт; просто зазначте, що було б всеосяжним чи «нейтральним», щоб розвиватись .)

Примітки:

• Ми очікуємо працювати з C, C ++, OpenCL, CUDA, Python.
• Ми - команда з 4 осіб + менеджер, який, як очікується, зросте приблизно до 5-6 протягом року.
• У нашій компанії команди майже повністю автономні і зазвичай взагалі не взаємодіють (навіть не використовуючи код один одного - робота ведеться за зовсім іншими проектами); тож - жодних міркувань для компанії.
• Щодо інструментів, на даний момент ми знаємо, що ми будемо використовувати Eclipse , тож його форматформа коду буде хоча б одним інструментом. Ctrl + Shift + F вже давно був моїм другом
• Коли я пишу Java, я прийняв практику максимально суворого дотримання ефективної Java від Bloch . Тепер це не зовсім стандарт кодування, але ви можете назвати деякі цегли, цемент і розчин для стандарту кодування. Я думав, можливо, включити щось подібне як частину "суміші" (маючи на увазі, що ми не робимо Java).
• Я маю в вигляді стандартів кодування в широкому сенсі цього слова, наприклад , приймаючи пропозиції , зроблені в відповіді на цей P.SE питання .
• Я знайшов великий список документів зі стандартом кодування C ++ ; можливо, я повинен видобути цю основу.
• (*) Це не зовсім вірно, але я не хочу ускладнювати це питання занадто великою кількістю конкретики.

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

Однозначно відповідь - так.

Зовнішній стандарт стандарт нічим не перевершує. Подивіться на відповіді в розділі " https://softwareengineering.stackexchange.com/q/84203/53019 ", щоб побачити деякі переваги наявності стандарту. Послідовність та наявність основи для зміни з критичної точки зору є вашими.

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

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

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

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

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

Я б почав з пітона. У Python є інструкції з кодування, за якими випливає майже кожен програміст python. Вони є частиною офіційної документації під назвою PEP8 .

C / C ++ - це величезний хаос з історичних причин, але оскільки python це не так, я б радив вам дотримуватися конвенції про іменування python у C / C ++ заради послідовності.

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

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

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

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

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

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

Також стандарти CERT є досить відомими та більш упередженими щодо настільного програмування та безпеки програмного забезпечення (а не безпеки). CERT мають стандарти для C, C ++, Java та Perl, а стандарти безкоштовні.

Я б почав з перегляду MISRA та CERT, а не якогось випадкового гаражного стандарту, знайденого в Інтернеті.

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

Якщо ви не впевнені, які стандарти кодування використовувати, є кілька очевидних ідеальних перших варіантів. Ні в якому конкретному порядку:
1. Незалежно від стандарту, який вже підтримується вашим IDE. Це, мабуть, можна налаштувати.
2. Який би стандарт не використовував / рекомендував автор вашого компілятора.
3. Який би стандарт не використовувався / рекомендований автором вашої основної рамки (якщо така існує).
4. Який би стандарт не використовувався / рекомендував автор (-и) / дизайнер (-ла) вашої мови програмування.
5. Залежно від того, який стандарт використовується / рекомендується дуже великою компанією.

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

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

Подивіться настанови Google для натхнення.

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

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

Я вважаю такі стандарти, як розташування та ім'я файлів, більш корисні1, ніж кодові (зрештою, код буває у всіх формах та розмірах, і вам все одно доведеться його читати), тоді як не знаючи readme.txt в / bin / doc / debug / випуск / документи - це справжній біль (як така хитра стежка, але це вже інша історія).

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

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