Чи є у вашої компанії стандарт кодування? [зачинено]

Нещодавно я побачив, що Microsoft випустила документ із стандартами кодування (Стандарти кодування All-In-One Framework Framework ), і це надумало мене ... Компанія, над якою працюю, взагалі не має офіційних стандартів кодування. Є лише кілька розробників, і ми були досить довго разом, щоб перерости в подібні стилі, і це ніколи не було проблемою.

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

Команді важливо мати єдиний стандарт кодування для кожної мови, щоб уникнути декількох проблем:

• Відсутність стандартів може зробити ваш код нечитабельним.
• Незгода щодо стандартів може спричинити війни за реєстрацію між розробниками.
• Бачити різні стандарти в одному класі може бути надзвичайно дратівливим.

Я великий фанат того, що дядько Боб має сказати про стандарти:

1. Нехай вони розвиваються протягом перших кількох ітерацій.
2. Нехай вони будуть конкретними для команди, а не для компанії.
3. Не записуйте їх, якщо зможете цього уникнути. Швидше, нехай код буде таким, як приймаються стандарти.
4. Не приймайте закон про хороший дизайн. (наприклад, не кажіть людям не користуватися goto)
5. Переконайтесь, що всі знають, що стандарт стосується спілкування, і нічого іншого.
6. Після перших кількох ітерацій зберіть команду разом, щоб прийняти рішення.

Я думаю, що важливо мати стандарт кодування, навіть якщо все, що він говорить, "ми використовуємо 3-пробільні відступи, а відкриті дужки переходять до наступного рядка". Кілька переваг:

• Це набагато полегшує читання через всю базу коду, оскільки перемикання стилів кодування між файлами дратує.
• Це полегшує читання одного файлу, оскільки будь-який файл, оновлений двома розробниками з конфліктуючими стилями, з часом, як правило, змішуватиме ці стилі. Читання файлу, який змішує вкладки та пробіли (та його редагування пізніше) - це біль у дупі.
• Новим розробникам полегшується використання хорошого стилю, якщо є явний стандарт, а не мається на увазі.
• Послідовне узгодження імен значно полегшує пошук функцій / змінних. Це ArraySort чи array_Sort чи sortTheArray чи doSortArray чи ...?

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

Я не погоджуюся з "ми - магазин X", тому ми форматуємо код на всіх мовах однаково.

Особисто я виявив, що більшість мов мають різні прийняті стилі.

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

Я думаю, що якщо у вас є стандарт, він повинен бути на одній мові

У мого колишнього роботодавця є стандарт кодування. Я також розглядаю формально документацію для себе.

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

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

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

Але, навіть гірше, хтось пише назви змінних та класів італійською мовою, хтось ще англійською ...

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

Майте на увазі, що це документ із стандартами кодування, який є специфічним для рамки коду "все в одному".

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

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

Обговорення стандартного кодування зводиться до цього:

• Так, вони вам потрібні, послідовність та чистий код - наріжний камінь гарного розвитку.
• Що вони майже не мають значення, доки всі дотримуються одних і тих же стандартів.
• Не пишіть своє, ви потрапляєте в нескінченну і болючу дискусію. Є багато там популярних.
• Використання державних стандартів (як, наприклад, MSDN ) дає вам третю сторону агностика, з якою не можна сперечатися. Якщо ви хочете сперечатися з ними, зверніться до пункту 2.

Якщо ви розробляєте C # у Visual Studio, то StyleCop - це срібна куля. Якщо ви також використовуєте ReSharper, то плагін StyleCop для ReSharper просто приголомшливий.

Ми цех, і ми використовуємо правила програмування.

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

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

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

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

Він може допомогти людям, а також може реально допомагати інструментами:

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

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

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