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

Приходилось ли вам когда-либо работать над стандартами кодирования, которые:

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

Если да, то какое правило вы предпочитаете меньше всего и почему?

Некоторые примеры здесь

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

1) Они всегда устарели, поскольку они слишком далеки от кода, который выполняет реальную работу, чтобы замечать, когда вы обновляете вещи. Плохие комментарии хуже, чем отсутствие комментариев.

2) Они часто просто повторяют информацию, которая уже содержится в инструменте контроля версий, просто менее точную. Например: Last Modified by, список даты / причин изменения.

Если бы у нас был профессор, который требовал, чтобы у нас был хотя бы один комментарий для каждой строки кода.

//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; это поощряет структурирование поверхности, а не фактическую структуру ОО.

В настоящее время я убиваю #REGIONs на месте.

На одной работе мы были вынуждены использовать странную форму венгерской нотации в базе данных.

Я не могу вспомнить детали, но по памяти каждое имя поля должно было содержать:

• Без гласных
• Все заглавные буквы
• Ссылка на таблицу
• Индикатор типа данных
• Длина данных
• Обнуляемый индикатор

Например, может называться столбец, содержащий имя человека: 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

Нью-Йорк Таймс весит в :

«Пространства слов не должны восприниматься как должное. Древнегреческий, первый алфавит с гласными буквами, можно расшифровать без пробелов, если вы озвучили его и обходились без них. […] Латынь тоже перестала разделять слова ко второму веку. Потеря озадачивает, потому что глаз должен работать намного усерднее, чтобы читать неразделенный текст. Но, как объяснил палеограф Пол Сэнгер, древний мир не желал «облегчить чтение и сделать его более быстрым».

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

Нам также было запрещено использовать программное обеспечение слияния; каждый файл может быть изменен только одним программистом одновременно. Конечно, программное обеспечение контроля версий было научной фантастикой.

Самый счастливый день в моей жизни был, когда его уволили (учтите, что очень и очень сложно кого-то уволить в Италии).

Все взаимодействие с базой данных должно осуществляться через хранимые процедуры . Это может иметь смысл, если мы живем в 1997 году, а не в 2010 году.

Я только что понял, что это на самом деле охватывает все критерии исходного вопроса:

• Сильно снизилась ваша производительность? ПРОВЕРИТЬ. Пожалуйста - просто используйте ORM .
• Первоначально были включены по уважительным причинам, но были сохранены еще долго после того, как первоначальная проблема стала неактуальной ПРОВЕРИТЬ. Менеджер был разработчиком для сервера базы данных 1000 лет назад и применил этот стандарт кодирования.
• Были ли в списке так долго, что было невозможно запомнить их всех? ПРОВЕРИТЬ. Это включало «как можно больше логики должно храниться в базе данных».
• Считаете ли вы, что автор просто пытался оставить свой след, а не поощрять хорошую практику кодирования? ПРОВЕРИТЬ. Продолжает возвращаться к менеджеру, являющемуся бывшим разработчиком сервера баз данных.
• Вы понятия не имели, почему они были включены? ПРОВЕРИТЬ.

Не разрешается использовать STL или другие стандартные библиотеки C ++, потому что технический директор полагал, что «мы» могли бы сделать это лучше и быстрее. Даже базовые конструкции, такие как списки и строковый класс.

Венгерская нотация

Образец, извлеченный из « Объяснения венгерского соглашения об именовании идентификаторов нотаций Чарльза Симони » в MSDN.

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

[Edit] Причина, по которой я упоминаю это как смехотворный стандарт, не в том, что я думаю, что комментарии к методам глупы, а в том, что качество этих комментариев не было применено каким-либо образом и привело к тому, что в кодовых файлах просто создавалось много беспорядка. , Существуют лучшие способы создания значимых документов кода, чем слепое требование «должен иметь комментарий».

Не совсем стандарт кодирования, но в контроле исходного кода был файл с именем changelog.txt.

Каждый раз, когда вы делали проверку, вам приходилось вручную добавлять запись в этот файл. Эта запись была номером ревизии subversion и вашим комментарием для регистрации.

Когда начался новый технический директор, и кто-то сказал ему об этом, он быстро принял исполнительное решение и сказал: «Мы больше не будем этого делать» и удалил файл. Это продолжалось годами.

В некоторых местах, с которыми я работал, требовалось комментировать неиспользуемый или устаревший код, а не удалять его. Вместо того, чтобы доверять VCS для истории и т. Д., Он мучительно поддерживался в файлах через закомментированный код.

Большая проблема, с которой я столкнулся, заключается в том, что вы часто понятия не имели, почему код был закомментирован. Было ли это потому, что какой-то разработчик активно вносил изменения и хотел оставить его для справки или он больше не нужен?

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

Использование встроенных комментариев для контроля версий было самым бессмысленным стандартом кодирования, который я игнорировал.

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

Oracle DBA, который настаивал на правильном использовании пробелов при «ведении» базы данных с помощью таблицы с высокой конкуренцией, содержащей более 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 миллионов на этом проекте, написанном на Java.

Проект Java представлял собой систему торговли акциями, предназначенную для обработки нескольких десятков акций, которая теперь использовалась для обработки тысяч. Вместо того чтобы устранять недостатки дизайна или плохое аппаратное обеспечение, вся компания была вынуждена конвертировать все приложения, не относящиеся к C / C ++, в C / C ++, и все новые разработки должны были выполняться на C / C ++. Интерпретирующие языки означают что-то не скомпилированное, и владелец рассматривал только скомпилированные ассемблер, C и C ++.

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

Забавно, но за двадцать лет до этого фиаско я был в другой компании, в которой технический руководитель решил, что нашу логику сортировки (это была Bubble Sort) необходимо перекодировать в ассемблере, а не заменять быстрой сортировкой, потому что - алгоритмы делают не улучшить производительность. Единственный способ повысить производительность - переписать ту же логику на ассемблере.

В обоих случаях я ушел вскоре после того, как велел диктат.

Как и многие программисты (но недостаточно), я ненавижу оформление кода. Меня бесит, когда мне приходится использовать префикс знака доллара ($) для имен переменных или подчеркивания для частных переменных, даже без использования методов получения / установки. Если вам нужно украсить свой код, чтобы понять его, то вам нужно черт побери!

Некоторое время я работал с веб-системой, где все передаваемые параметры должны были называться P1, P2, P3 и т. Д. У меня не было шансов узнать, для чего они нужны, без обширной документации.

Кроме того - хотя это не является строго стандартом кодирования - в одной и той же системе каждый отдельный файл должен был называться xyz0001.ext, xyz0002.ext, xyz0003.ext и т. Д., Где xyz был кодом для самого приложения.

Это было долгое время назад - 1976, если быть точным. Мой начальник никогда не слышал об Эдсгере Дейкстре и не читал о проблеме CACM, но откуда-то слышал слух, что «GOTO плох», поэтому нам не разрешали использовать GOTO в наших программах на COBOL. Это было до того, как COBOL добавил «конец, если», поэтому в то время у него было только две с половиной из трех классических структур управления (последовательность, если / то / еще, выполнять (то есть делать, пока)). Он неохотно разрешил GOTO в наших Базовых программах и инструкции по веткам в наших языковых программах на Ассемблере.

Извините, что это своего рода история "ты должен был быть там". Насколько я знаю, каждый язык, изобретенный с 1976 года, имеет адекватные структуры управления, так что вам никогда не нужно использовать GOTO. Но дело в том, что начальник никогда не знал, ПОЧЕМУ GOTO считался вредным, или какой язык был детским расстройством, а какой - смертельным заболеванием.

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

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

Даже ReSharper сказал вам, что это неправильно!

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

• Не используйте включает. Мне нравится одна большая страница
• Всегда разделяйте слова в именах переменных и столбцов с подчеркиванием (кроме isactive, firstname и т. Д.)
• Никогда не используйте сокращения - всегда пишите имя (он часто пишет fname и т. Д.)
• Не используйте запутанные имена (например, amount_charged и charge_amount, которые измеряют разные, но связанные вещи)
• Не использовать DIVs , а используйте минимальный CSS - используйте вместо этого вложенные таблицы (я обнаружил, что у меня было шесть слоев глубиной, один раз).
• Не кешируйте какие-либо запросы. Когда-либо.
• Собираетесь использовать переменную на более чем одной странице? Область применения.
• Каждая страница является собственным блоком try / catch. Нам не нужен / не нужен глобальный обработчик ошибок.

Я начал менять их, как только он ушел.

В моей жизни как программиста на 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;
}