Найгірший стандарт кодування, якому ви коли-небудь дотримувалися? [зачинено]

Вам коли-небудь доводилося працювати над стандартами кодування, які:

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

Якщо так, то яке найменше улюблене правило і чому?

Деякі приклади тут

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

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

2) Вони часто просто повторюють інформацію, яка вже міститься в інструменті управління джерелами, лише менш точною. Наприклад: Остання зміна, перелік дати / причини зміни.

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

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

Це було досить смішно.

Наш стандарт кодування (C #) вимагає широкого використання #REGION (для тих, хто не знає, він позначає блоки вихідного коду, які будуть згортатись до однієї лінії у Visual Studio). Як наслідок, ви завжди відкривали те, що, здавалося, добре структурований клас, лише знаходили палі та купи сміття, прокинуті під глибоко вкладеними килимами конструкцій #REGION. У вас навіть є регіони навколо окремих рядків, наприклад, потрібно скласти складку області LOG, щоб знайти одну єдину заяву Logger. Звичайно, безліч методів, доданих після створення деяких регіонів, також були розміщені в "неправильному" регіоні. Жах. Жах.

Регіони - одна з найгірших функцій, що коли-небудь додаються до Visual Studio; це заохочує структурувати поверхню, а не фактичну структуру ОО.

У наш час я вбиваю #REGION на виду.

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

Я не можу згадати деталі, але з пам’яті кожне ім’я поля повинно містити:

• Без голосних
• Усі великі літери
• Посилання на таблицю
• Індикатор типу даних
• Довжина даних
• Нульовий показник

Наприклад, стовпець, що містить ім’я людини, може називатися: PRSNFRSTNMVC30X(таблиця особи, стовпець імені, 30 символів Varchar, не нуль)

Наполягаючи, що за всіма дужками слід коментувати, чим закінчується дужка:

наприклад:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'Нафф сказав.

• Імена локальних змінних - це малі регістри без підкреслень

Реальні приклади: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

The New York Times важить :

«Пробіли у словах не слід сприймати як належне. Давньогрецька мова, перша абетка з голосними голосами, може розшифруватися без пробілів слів, якби ви озвучили це, і обійшлося без них. […] Латина теж перестала відокремлювати слова до другого століття. Втрата викликає спантеличення, адже око мусить працювати набагато важче, щоб прочитати нерозділений текст. Але, як пояснив палеограф Пол Саенгер, стародавній світ не бажав "зробити читання легшим і швидшим".

Мене попросили лідера програмного забезпечення компанії , щоб зробити « простий, ре н dundant код ». Наприклад, було заборонено додавати новий параметр до існуючої функції. Натомість вам довелося дублювати функцію, залишаючи оригінал недоторканим, щоб уникнути регресій. Ніякого офіційного тестування курсу (марна трата часу).

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

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

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

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

• Значно знизили свою продуктивність? ПЕРЕВІРИТЕ. Будь ласка - просто використовуйте ORM .
• Спочатку вони були включені з поважних причин, але їх зберігали довго після того, як первісне занепокоєння стало неактуальним? ПЕРЕВІРИТЕ. Менеджер був розробником для сервера баз даних 1000 років тому і застосував цей стандарт кодування.
• Були в списку так довго, що неможливо було їх усіх запам'ятати? ПЕРЕВІРИТЕ. Це включало "якомога більше логіки має зберігатися в базі даних".
• Змусили вас думати, що автор просто намагався залишити свій слід, а не заохочувати добру практику кодування? ПЕРЕВІРИТЕ. Тримається повернення до менеджера як колишнього розробника сервера баз даних.
• Ви не мали уявлення, чому їх включили? ПЕРЕВІРИТЕ.

Не дозволяється використовувати STL або інші стандартні бібліотеки C ++, оскільки CTO вважає, що "ми" можемо зробити це краще і швидше. Навіть основні конструкції, такі як списки та клас рядків.

Угорська нотація

Зразок, витягнутий з " експлікації Чарльза Симоні угорського ідентифікатора нотації іменування конвенції " на MSDN.

1 #включіть "sy.h"
2 extern int * rgwDic;
3 extern int bsyMac;
4 структура SY * PsySz (char sz [])
6 {
7 char * pch;
8 int cch;
9 структура SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 без підпису wHash = 0;
13 pch = sz;
14 while (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 для (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 char * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 час (* pch == * szSy ++)
24 {
25, якщо (* pch ++ == 0)
26 повернення (пси);
27}
28}
29 cwSz = 0;
30, якщо (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 Нульова ((int *) пси, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 повернення (пси);
36}

Я колись працював над проектом, в якому керівництво проекту вимагало, щоб кожна змінна - КОЖНА змінна - мала префікс "v". Отже, vCount, vFirstName, vIsWarranty тощо.

Чому? "Тому що ми працюємо в VBScript і все одно є варіантом".

WTF.

Майже забув це:

Цитата керівника:

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

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

Розширені коментарі XML щодо всіх неприватних методів, констант, перерахунків та властивостей.

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

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

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

Насправді не стандарт кодування, але у нас був файл у керуванні джерелом під назвою "changelog.txt"

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

Коли запустився новий КТО, і хтось сказав йому це, він негайно прийняв виконавче рішення і сказав: "Ми більше не будемо цього робити" і видалив файл. Це тривало роками.

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

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

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

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

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

OBA Dracle, який наполягав на правильному використанні пробілів, «підтримуючи» базу даних з дуже суперечливою таблицею, яка мала понад 200 полів і 40 тригерів.

Я робив огляд коду на проект, керований першим таймером C ++, який вирішив, що всі функції класу повинні бути встановлені з назвою класу та видимістю:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

Потрібно відступити весь код на чотири пробіли;)

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

Це більше приклад того, як відсутність стандартів кодування може нашкодити.

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

• Все в верхньому регістрі. Я маю на увазі все, включаючи рідкісні коментарі, які він зробив.
• Відступів немає.
• Змінне іменування було чимось уздовж APRGNAME. A = область змінної, наприклад, P для загальнодоступних, PRG = перші три символи вихідного файлу, який створив змінну, NAME = ім'я змінної в інших 6 символах, дозволених dBase / Clipper.
• Перші 4 та останні 4 рядки вихідного коду були довжиною 80 *. Чому? Тож він міг почути точковий матричний принтер, починаючи та закінчуючи друк файлу. Пам'ять - вся програма була надрукована через мейнфрейм щотижня, 20000 сторінок.
• Я впевнений, було ще багато, що мені вдалося скинути з мозку.

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

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

Ще один вибух з мого минулого.

Цитата від власника компанії:

Код, написаний на інтерпретаційних мовах, не буде, оскільки я втратив 25 мільйонів на проекті {expletive}, написаному на Java.

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

Для компанії на 800 осіб, у якій більша частина коду була на Яві та Perl, це означало, що ціла компанія витрачала більшу частину свого часу протягом наступних двох років, переписуючи ідеально чудовий код на C / C ++.

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

В обох випадках я пішов незабаром після того, як диктат зійшов.

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

Я деякий час працював з веб-системою, де всі параметри, що були передані, мали бути названі P1, P2, P3 і т.д.

Також - хоча це не є строго стандартним кодуванням - в одній і тій же системі кожен окремий файл повинен був називатися xyz0001.ext, xyz0002.ext, xyz0003.ext тощо - де xyz був самим кодом програми.

Це було ДОЛГИ час тому - 1976 рік, якщо бути точним. Мій бос ніколи не чув про Едсгера Дайкстра чи читав випуск CACM, але він звідкись почув слух, що "GOTO - це погано", тому нам не дозволяли використовувати GOTO в наших програмах COBOL. Це було до того, як COBOL додав "кінець якщо", тому на той час у нього було лише дві з половиною з трьох класичних структур управління (послідовність, якщо / потім / інше, виконувати (тобто виконувати поки)). Він з недоліком дозволив GOTO в наших Основних програмах, а також вручних інструкцій у наших мовних програмах Assembler.

Вибачте, що це свого роду історія "ви повинні були там бути". Наскільки мені відомо, кожна мова, винайдена з 1976 року, має адекватні структури управління, так що вам ніколи не потрібно використовувати GOTO. Але справа в тому, що начальник ніколи не знав, ЧОМУ ГОТО вважається шкідливим, або яка мова була інфантильним розладом, а яка - смертельним захворюванням.

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

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Навіть ReSharper сказав вам, що це неправильно!

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

• Не використовуйте включає. Мені подобається одна велика сторінка
• Завжди відокремлюйте слова у назвах змінних та стовпців із підкресленнями (крім активної, імені тощо)
• Ніколи не використовуйте скорочення - завжди виписуйте прізвище (він часто писав ім’я та ін.)
• Не використовуйте заплутані імена (наприклад, кількість_зарядка та рахунок_зарахування, які вимірювали різні, але пов’язані з цим речі)
• Не використовуйте DIV , а використовуйте мінімальний CSS - замість цього використовуйте вкладені таблиці (я знайшов кілька шести шарів глибоко).
• Не кешуйте жодних запитів. Колись.
• Збираєтесь використовувати змінну на більш ніж одній сторінці? Область застосування
• Кожна сторінка є власним блоком спробу / лову. Нам не потрібен / хочемо обробник глобальних помилок.

Я почав змінювати їх, як тільки він кинув.

У моєму житті як кодер C ++ були застосовані два справді противні "правила":

1. "Ми не можемо використовувати STL, оскільки VC ++ 4.1 не підтримує його (і ми не можемо перейти на VC ++ 6.0 на даний момент)."
2. «Не НЕ використовувати QuickSort, тому що це може бути O (N ^ 2) у важких випадках, використовувати цю реалізацію алгоритму пірамідальної сортування I (ім'я керівника проекту видалено) написала в якості студента.»

Я змушений мати документацію XML для всіх класів та членів класу. У тому числі приватні. Мене спонукає використовувати коментарі ghostdoc за замовчуванням.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}