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

77

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

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

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


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

finnw
источник
4
Кстати, я задавал похожий вопрос (но не совсем тот же) о SO раньше: stackoverflow.com/questions/218123/…
Брайан Р. Бонди,
@ Брайан, спасибо, я видел твой вопрос, но забыл об этом.
Финнв
4
Настоящая проблема со стандартами кодирования заключается в потере времени и усилий, споря о том, верны они или нет. Ничто не сравнится с кудрявой войной за создание междоусобной розни ...
MZB

Ответы:

97

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

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

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

JohnFx
источник
12
Я нахожу (по крайней мере сейчас, раньше в школе, что казалось странным), что вообще комментировать - плохая практика
Шейди М. Наджиб,
14
Мало того, но я обнаружил, что накладные расходы, связанные с созданием нового файла классов, когда вам нужно поместить нагрузку на шаблон сверху, фактически отговаривают разработчиков от создания новых классов и поощряют огромные громоздкие классы и, следовательно, плохой дизайн.
Газ
13
Не согласен! Мы не добавляем бесполезную или избыточную информацию, а просто текстовое объяснение того, что делает функция (в файле .h), и это так полезно! Конечно, мы стремимся поддерживать его в синхронизации с кодом.
Волшебник
5
@Shady M Наджиб всегда плохой или плохой, когда ему позволяют оставаться без контроля / без присмотра? Как правило, хороший код делает свою цель достаточно очевидной, чтобы избежать необходимости в комментариях, но это не всегда так, и я чувствую, что в этих сценариях комментирование имеет решающее значение. Я не могу придумать одну плохую причину для включения комментариев XMLDoc.
Натан Тейлор
7
Блок, объясняющий, что он делает, это хорошо. Блок просто повторяет типы и имена аргументов и возвращаемого значения, это плохо. Когда мне пришлось работать со стандартным мандатом последнего, я написал сценарий emacs для автоматической генерации большинства из них.
AShelly
130

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

//Set x to 3
var x = 3;

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

    //Print x
    Print(x);
}

Это было довольно смешно.

Fishtoaster
источник
10
Разве это не значит, что профессор знает, что вы точно знаете, что происходит?
Джон Макинтайр
80
Я думаю, что понятно, что происходит, и это не образование.
Дэн Рэй
18
Приведенный выше пример понятен, но что, если студент скопирует вызов какой-либо функции из другого приложения или книги или чего-то еще и не поймет этого? Как профессор узнает? Это глупое правило не допускает никаких серых областей (которые в его защиту, вероятно, использовались ранее). Вот как я это интерпретирую. ... заметьте, если я увижу это в неакадемической среде, это может меня немного напугать. ;-)
Джон Макинтайр,
4
Да, за исключением того, что вы всегда можете написать комментарии, которые просто повторяют код и не показывают никакого понимания. Делает ли он вас правильно "// Конечная скобка" перед конечной скобкой?
альтернатива
6
Что, если вы случайно получили полезный комментарий в своем коде? Вы должны поставить // commentна линию до этого?
конфигуратор
103

Наш корпоративный (C #) стандарт кодирования требовал широкого использования #REGION (для тех, кто не знает, он помечает блоки исходного кода, которые будут свернуты в одну строку в Visual Studio). Как следствие, вы всегда открывали то, что казалось хорошо структурированным классом, только для того, чтобы находить груды мусора, попадающие под глубоко вложенные коврики конструкций #REGION. У вас даже были бы области вокруг одной строки, например, вам нужно было бы свернуть область LOG, чтобы найти одну единственную декларацию Logger. Конечно, множество методов, добавленных после того, как был создан какой-то регион, также были помещены в область «неправильного» региона. Ужас. Ужас.

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

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

оборота Кумбая
источник
11
Я пытался проголосовать за это дюжину раз ...
TGnat
22
Если вы думаете, что вам нужно #REGION, я думаю, вам нужно рефакторинг.
Джей Базузи
23
Я обычно организую код по областям в конструкторы, свойства, события, методы и члены. Это облегчает управление и навигацию по источнику (особенно в некоторых статических служебных классах, которые могут стать довольно большими). Я не буду использовать их больше, чем это все же.
Эван Плейс
26
У нас есть простой стандарт кодирования: никогда не вкладывать регионы. Просто используйте их для группировки связанных методов (инициализация, сериализация, свойства и т. Д.)
Джейсон Уильямс,
6
Единственная хорошая цель #regions - скрыть код, который не нужно редактировать . Это может быть сгенерированный код или код с трудным для понимания алгоритмом, который вы бы предпочли не трогать, или уродливые блоки кода отладки. Но не код, над которым люди будут работать. Для тех, кто застрял в магазине #region, у меня есть макрос, который сворачивается в определения, но расширяет регионы. Смотрите здесь: stackoverflow.com/questions/523220/awesome-visual-studio-macros/…
Kyralessa
80

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

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

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

Например, может называться столбец, содержащий имя человека: PRSNFRSTNMVC30X(таблица «Персона», столбец «Имя», 30 символов Varchar, не ноль)

Damovisa
источник
14
Извините, но что происходит, когда вы реорганизуете базу данных или когда вы решаете, что длина VARCHAR должна быть другой. Внезапно, вы должны пройти через весь ваш код и изменить ... о боже. Это выглядит ужасно.
Том Моррис
71
Нет гласных ??! Вы шутите, верно?
Дэниел Кэссиди
39
У людей, которые следовали этому стандарту, были лбы на лбу и они часто обсуждали честь и битву?
Райан Робертс
10
Ха-ха, ну, они были администраторы баз данных, так что ...;)
Дамовиса
14
Вы должны были отправить имена столбцов через URL-адрес. PersonFirstNameVarchar30NotNull = bit.ly/cULlQc
Билли Кувер,
48

Настаивая на том, что за всеми фигурными скобками следует комментарий для определения того, что фигурная скобка заканчивается:

например:

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
Крис Эриксон
источник
21
Более разумный: если вам нужен комментарий, чтобы сказать, каким был начало блока, то блок слишком длинный или его содержание слишком сложное => рефакторинг.
Ричард
5
Я хочу проголосовать, потому что длинные, глубоко вложенные блоки трудно разобрать, и эти комментарии могут помочь. Я хочу проголосовать, потому что эти комментарии станут неправильными (и очень запутанными) довольно скоро, и потому что длинные, глубоко вложенные блоки являются признаком того, что вам нужно реорганизовать, а не добавлять больше комментариев.
Джей Базузи
7
это была отличная идея для мира без мощной IDE.
IAdapter,
9
@ Сойка в любой приличной среде вы можете выделить одну фигурную скобку, а другую - соответствующую. Я лично ненавижу, когда люди делают это.
Эван Плейс
3
Хотя ваш пример немного сумасшедший (поскольку он недостаточно длинный, чтобы это имело значение и замедлял вас при смене логики), это не всегда плохо. Подобные комментарии действительно полезны для закрытия пространств имен / объявлений endif, которые охватывают весь файл.
Йтернберг
38
#define AND  &&
#define OR   ||
#define EQ   ==

'достаточно.

Найл С.
источник
9
Разве #include <iso646.h> не будет намного лучшим выбором?
AndrejaKo
3
@AndrejaKo: это предшествовало <iso646.h>; это была попытка сделать C похожим на Фортран.
Найл С.
2
Это действительно был стандарт кодирования? т.е. была ли политика компании против написания операторов напрямую?
Finnw
21
Это также имеет #define BEGIN {и #DEFINE END }?
JBRWilkinson
3
Это напоминает мне статью о Daily WTF, которую я видел, у некоторых программистов на C ++ было множество определений, чтобы она выглядела как Visual Basic (или, может быть, просто Basic, какой-то диалект). #define void Sub, #define} Конец и тому подобное.
Уэйн Молина
37
  • Все имена локальных переменных строчные без подчеркивания

Реальные примеры: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

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

«Пространства слов не должны восприниматься как должное. Древнегреческий, первый алфавит с гласными буквами, можно расшифровать без пробелов, если вы озвучили его и обходились без них. […] Латынь тоже перестала разделять слова ко второму веку. Потеря озадачивает, потому что глаз должен работать намного усерднее, чтобы читать неразделенный текст. Но, как объяснил палеограф Пол Сэнгер, древний мир не желал «облегчить чтение и сделать его более быстрым».
John Siracusa
источник
3
+1. Незначительные неприятности складываются. Кроме того, с ними трудно поспорить, потому что редактор стандартов кодирования или премьер-министр могут сказать: «Это не большая нагрузка, поэтому не стоит ее менять».
Finnw
1
Именно так. (Хотя в этом случае чтение бесчисленных имен переменных, таких как this, действительно adduptoquitea greatburden.)
Джон Сиракуза,
57
Развлекайся, придумывая имена, а потом разбирайся двумя способами. Payshits, Penisup и т. д.
Джей Базузи
4
@Jay * sexchange
конфигуратор
2
@configurator: Когда команда отладчика Visual Studio работала над функцией, позволяющей вам видеть исключение в данный момент в полете, в окне наблюдения, они собирались добавить псевдо-переменную с именем «$ ex». Мы давно не замечали. Затем мы переименовали в «$ exception», но я все еще читаю это как «s».
Джей Базузи
36

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

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

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

Lorenzo
источник
он, возможно, никогда не слышал слово «рефакторинг»
Нанда
3
Он никогда не слышал также много других слов ...
Wizard79
Ну, вам не нужно формальное тестирование, потому что вы никогда не меняли методы ...
Конфигуратор
36

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

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

  • Сильно снизилась ваша производительность? ПРОВЕРИТЬ. Пожалуйста - просто используйте ORM .
  • Первоначально были включены по уважительным причинам, но были сохранены еще долго после того, как первоначальная проблема стала неактуальной ПРОВЕРИТЬ. Менеджер был разработчиком для сервера базы данных 1000 лет назад и применил этот стандарт кодирования.
  • Были ли в списке так долго, что было невозможно запомнить их всех? ПРОВЕРИТЬ. Это включало «как можно больше логики должно храниться в базе данных».
  • Считаете ли вы, что автор просто пытался оставить свой след, а не поощрять хорошую практику кодирования? ПРОВЕРИТЬ. Продолжает возвращаться к менеджеру, являющемуся бывшим разработчиком сервера баз данных.
  • Вы понятия не имели, почему они были включены? ПРОВЕРИТЬ.
Jaco Pretorius
источник
2
У нас есть люди в этом лагере на моем рабочем месте. Забавно, когда они пытаются разыграть карту производительности и показать, насколько устарели их знания
восстановить Монику
3
подождите .. со всей серьезностью, я думал, что SP лучше, с точки зрения производительности, чем прямые вызовы SQL, скажем, из C #?
Sk93
3
Похоже, вы точно знаете, почему они были включены. : P
Мейсон Уилер
4
Когда я вырос, я наконец понял, почему все должно проходить через БД :) На полном серьезе это упрощает многие вещи, не пытайтесь заново изобретать колесо.
Jé Queue
3
Я слышал приятные рассуждения: «Мы не можем использовать OR / M, потому что все взаимодействия должны использовать SP». Такая трата человеческой силы.
конфигуратор
33

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

Дэвид Б
источник
5
Единственный раз, когда я слышал о том, чтобы кто-нибудь не использовал STL, потому что он был недостаточно быстрым и был прав, был для игр. EA сделала собственную реализацию STL для своих игр. Я сильно сомневаюсь, что это имеет значение больше (современные игры ограничены GPU), и я сомневаюсь, что они используют это. Но даже все же это была реализация STL, а не целая новая библиотека. Вы все еще использовали STL при использовании EASTL.
Мэтт Оленик
1
@Matt: чтобы добавить к этому, жалоба EA была сосредоточена на использовании памяти и инициализации. Их собственная реализация потребляла меньше памяти, освобождала ее раньше и избегала инициализации объектов, которые будут инициализированы позже.
Матье М.
Я бы сказал ему самому кодировать.
праву
31

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

Образец, извлеченный из « Объяснения венгерского соглашения об именовании идентификаторов нотаций Чарльза Симони » в 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}
J8D
источник
5
Ой ой ой ой ой ой!
Восстановить Монику
22
Самая большая проблема в этом примере - бессмысленные имена переменных. Удалите венгерские префиксы, и некоторые из них имеют длину 1 или даже 0 символов.
Finnw
8
Это системный венгерский язык, который полезен в языках со слабой типизацией (поскольку он кодирует информацию о типе, которая важна для работы в этих языках в именах) - он бесполезен в строго типизированных языках. Лучшей альтернативой для строго типизированных языков является Apps Hungarian, который кодирует важную информацию об использовании переменной (member, pointer, volatile, indexer) - то, что сам язык не поддерживает.
Джейсон Уильямс
5
Прошу вас. Я никогда никогда не путать местный с членом, и я не использую эту глупую венгерски для членов / местных жителей / полей / независимо. Я думаю, что они могут быть полезны для различения различных типов строк, таких как «безопасные» и «небезопасные», как пример Джоэла в статье «Неправильный код выглядит неправильно»
конфигуратор
3
@configurator: пример Джоэла ужасен, ему было бы лучше иметь разные типы, тогда компилятор принудительно использовал бы его.
Матье М.
28

Однажды я работал над проектом, в котором руководитель проекта предписывал, чтобы каждая переменная - КАЖДАЯ переменная - имела префикс «v». Итак, vCount, vFirstName, vIsWarranty и т. Д.

Почему? «Потому что мы работаем в VBScript, и все равно это вариант».

WTF.

Кристофер Хокинс
источник
93
Однажды я работал на языке, который требовал, чтобы каждая переменная - КАЖДАЯ переменная - имела префикс "$".
nohat
6
@nohat: И ты понял, что это было удивительно, не так ли?
Джош К
Я когда-то работал на языке, где все мои переменные начинались с пунктуации, как '$' или '%' или '@'. Я до сих пор, сейчас и потом.
Дэвид Торнли
3
Это действительно становится проблемой только тогда, когда вам нужно поставить fперед функциями, тогда ваш код действительно fUcked (vUp).
Джо Д
1
Похоже, различные версии Perl ...
26

Почти забыл этот:

Цитата из менеджера:

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

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

Дэвид Б
источник
2
Это ужасная политика. Я надеюсь, что этот менеджер был консервирован.
Бернард
@ Бернард-В большинстве организаций создание долгосрочного потока доходов является основанием для быстрого продвижения. Надеюсь, кто-то еще увидел в этом безумие и случайно столкнул его на парковку.
Джим Раш
24

Внедренные XML-комментарии ко всем не приватным методам, константам, перечислениям и свойствам.

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

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

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

Анна Лир
источник
13
' Validations the handler' - э-э-э
Эрик
8
+1 Тьфу, я ненавижу это. Я думаю, что если вы используете программное обеспечение для создания комментариев, то они вам не нужны.
Блеево
9
Я не думаю, что это плохое правило. При чтении метода, который я должен поддерживать в первый раз, очень помогает, если у меня есть спецификации для всех аргументов. Есть обычные тонкости (например, что происходит, если аргумент равен нулю, что если это пустая коллекция, имя несуществующего файла и т. Д.). Другое хорошее (IMHO) правило - имена методов должны быть глаголами, но в вашем примере это существительное.
Finnw
3
@ finnw Я думаю, что это хорошая практика, но плохой стандарт. Если разработчики работают и пишут содержательные комментарии к методам, когда они гарантированы (подробности исключений и т. Д.), Это здорово. Если нет, то вы получите большой беспорядок. И в первом случае вам вообще не нужно принудительное применение на уровне компиляции.
Адам Лир
7
Классический случай недокументирования. Комментарии, которые ничего не говорят, кроме явно очевидного, должны быть убиты на месте.
Cumbayah
23

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

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

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

Jim A
источник
6
И никто не знал об этом svn log?
Htbaa
1
Те, кто начал политику, давно ушли, а те, кто следовал, продолжали ее. Я начал в ту же неделю, что и новый технический директор (мой друг), и мы оба посмотрели на это и сказали WTF?
Джим А
20

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

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

Джереми Вибе
источник
3
Недавно я удалил много старого закомментированного кода.
CoderDennis
2
Я обычно удаляю закомментированный код, если он не сопровождается хорошим объяснением того, почему он закомментирован и почему его следует хранить на месте.
Джереми Уибе
Я абсолютно согласен. Комментировать код до тех пор, пока вы работаете с ним, это нормально, но все, что входит в релизную версию / основную ветку, должно быть лишено закомментированного кода. Кто-то сказал мне, что им «нравится знать, как это можно сделать по-другому». Я просто нахожу это раздражающим по причинам, упомянутым: это устарело, обходной путь, другой способ сделать это? WTF
Anne Schuessler
С VS2013 "Peeks" это все за окном. Но мы помещаем комментарий, который говорит: «Измененное уравнение - инициалы» или что-то в этом роде, поэтому кто-то задается вопросом, каким был бы старый код, и посмотрел бы в TFS / VCS, если это необходимо. Таким образом, это одна строка вместо 10 закомментированных строк. Но VS2013 потрясающий, он показывает историю TFS прямо для вас.
Суамер,
17

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

JaredPar
источник
16

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

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

Oracle DBA, который настаивал на правильном использовании пробелов при «ведении» базы данных с помощью таблицы с высокой конкуренцией, содержащей более 200 полей и 40 триггеров, подходит к концу.

Райан Робертс
источник
Это довольно отвратительно
Эван Плейс
5
Ммм. Дим Сум ...
конфигуратор
Я сделал это, конечно, до того, как мы установили контроль над источниками. После того, как у нас появился контроль над источниками, это стало такой привычкой, что нам практически потребовалось вмешательство, чтобы команда перестала это делать. В конце концов мы остановились и удалили все существующие, когда нашли их.
Скотт Уитлок
Наш старший разработчик все еще пытается заставить нас сделать это. Я игнорирую политику всякий раз, когда я думаю, что могу сойти с рук (и иногда, когда я знаю, что не могу).
Джошуа Смит
У нас в команде есть парень, который до сих пор делает это повсюду (он также включает в себя огромные вещи из «Журнала изменений» в наших сценариях SQL, которые также находятся под контролем версий). Аргумент, как мне объяснили, заключается в том, что после нескольких изменений / фиксаций вы не помните дату, когда что-то было изменено, поэтому в журнале изменений можно сразу заметить, кто что изменил и почему, когда вы открываете файл.
Уэйн Молина
14

Я сделал обзоры кода в проекте под руководством первого таймера C ++, который решил, что все функции-члены класса должны иметь префикс с именем класса и видимостью:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}
user1006
источник
1
Вы спросили их, почему ? Я просто хотел бы знать их мотивацию ..
JBRWilkinson
1
Вау, почему этот парень даже использует классы ?
Матин Улхак
9

Требуется отступ всего кода на четыре пробела;)

RedFilter
источник
2
Как это было плохо?
Джей Базузи
1
Потому что тогда в каждой строке есть 4 ненужных пробела в начале?
nohat
О, теперь я понял.
альтернатива
21
Да, в StackOverflow действительно плохой стандарт кодирования. :-)
P Швед
Большие отступы заставляют вас поддерживать низкий уровень вложенности кода. Я видел отступы 8, и он работал нормально.
Toon Krijthe
9

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

Джереми
источник
Это ужасный, ужасный стандарт кодирования, которому нужно следовать. И глупая причина для этого тоже!
Габлин
4
Если вам нужно прокрутить горизонтально (например, больше половины страницы), возможно, что-то не так. Отступы тоже не годятся, так как они делают код полностью нечитаемым. Я стараюсь придерживаться лимита в 78 колов, но, если требуется, превышать эту сумму, я не против, но я стараюсь избегать этого.
Htbaa
8

Это еще один пример того, как отсутствие стандартов кодирования может повредить.

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

  • Все в верхнем регистре. Я имею в виду все, включая редкие комментарии, которые он сделал.
  • Нет отступа.
  • Именование переменных было чем-то вроде APRGNAME. A = область видимости переменной, например, P для общедоступного, PRG = первые три символа исходного файла, создавшего переменную, NAME = имя переменной в оставшихся 6 символах, разрешенных dBase / Clipper.
  • Первые 4 и последние 4 строки исходного кода были длиной 80 *. Почему? Поэтому он мог слышать, как матричный принтер запускает и заканчивает печать файла. Память всей программы была напечатана через мэйнфрейм в неделю, 20000 страниц.
  • Я уверен, что было еще много, что мне удалось выбросить из моего мозга.

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

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

Тим Мерфи
источник
7
Не издевайтесь над старшими динозаврами, пожалуйста. Они сделали нас возможными.
П Швед
4
Похоже, безопасность работы.
МВД
7
Наличие аудио-маркера, чтобы вы знали, когда каждый файл печатается, гениально. Я собираюсь добавить \07в начало каждого файла сейчас.
конфигуратор
2
Использование такой схемы именования (не в верхнем регистре) имело некоторый смысл, так как правила определения области действия dBase не существовали. Все было эффективно глобально. iИспользуется для индексирования массива в одной процедуре может помешать с iв процедуре вызова. Вам нужно использовать PRIVATE ALL LIKE m*и PRIVATE iпредотвратить эту «слежку»
Gerry
8

Еще один взрыв из моего прошлого.

Цитата от владельца компании:

Не будет никакого кода, написанного на интерпретирующих языках, потому что я потерял 25 миллионов на этом проекте, написанном на Java.

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

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

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

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

Дэвид Б
источник
Сегодня какая-то компания работает?
Finnw
Тот, который «сдвинулся» с Java, другой давно исчез. Они так и не пережили переход от TRS-80 к ПК.
Дэвид Б
6

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

Адам Харт
источник
Ну, как говорит «Уилл»: «Я добавляю подчеркивание, чтобы мои личные переменные были сгруппированы в моем значении. Однако я делаю это только для переменных, ограниченных типом. Переменные, объявленные в методе или в более узкой области, я оставляю подчеркивание off. Позволяет легко разделить их и хранить вместе менее используемые переменные. " и я должен согласиться с ним.
7
1
Я не думаю, что группирование ваших переменных в вашей любимой проприетарной IDE - это достаточно веская причина, чтобы испортить весь ваш код.
Адам Харт
Если это ваш код, сделать его пригодным для использования в вашей IDE кажется вполне разумным. Кроме того, предварительные подчеркивания распространены во многих языках, поэтому, когда люди видят это, они знают, что это значит.
Rjmunro
1
+1 Использование хорошей IDE (которая может использовать поиск по регулярным выражениям ) имеет больше смысла для меня. Очистите IDE, научитесь пользоваться текстовым редактором и терминалом, и вы станете намного лучше программистом. В качестве примечания, мне не особо нравятся символы Perl, но, по крайней мере, они используются, в отличие от PHP.
альтернатива
6
Вздох ... еще один из тех "IDE's for pussies".
Nailer
6

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

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

CB Du Rietz
источник
6

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

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

Марк Луттон
источник
6

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

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

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

Jax
источник
9
Вам будет трудно вернуть что-то из функции, объявленной как void.
Мирча Chirea
7
@MAttB Рассмотрим, при каких условиях elseбудет выполняться ветвь final ( ).
Ричард
6
else {return string.Empty; } выполнится, когда вышеперечисленные 2 строки были отредактированы разработчиком сопровождения через 5 лет. Однако, возвращая string.Empty скроет тот факт, что раньше было невозможным условием. Вместо этого он должен генерировать InvalidOperationException («Этот код не предназначен для поддержки логики трех значений»);
MatthewMartin
1
Это ужасно Что случилось сreturn verbose ? someString : someOtherString; ?
Каллум Роджерс
1
@callum Тернарный оператор может быть забанен :) бывал там раньше ...
hplbsh
6

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

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

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

Ben Doom
источник
«Не используйте запутанные имена» кажется мне достаточно справедливым ...
8128
1
Это абсолютно справедливое руководство. Я хотел сказать, что он вообще не следовал этому. Я предполагаю, что его идея «не путать» и моя были другими.
Бен Дум
4

В моей жизни как программиста на C ++ были соблюдены два очень неприятных «правила»:

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

источник
6
Что не так с HeapSort руководителя проекта?
7
4
На самом деле, если код принят внешним пользовательским вводом, QuickSort может быть неправильным, поскольку он открывается для O(n^2)DOS-атак (подача ввода в худшем случае). Кроме того, почему не было возможности переключиться - это само по себе оправдание отказа от использования STL.
Мацей Пехотка
4

Я вынужден иметь документацию XML для всех классов и членов класса. В том числе частный. Я очень рад использовать комментарии ghostdoc по умолчанию.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}
Карл Бергквист
источник
Очень похоже на этот предыдущий ответ .
2010 года
Да. Все, что я должен комментировать частные члены также. Что имеет еще меньше смысла.
Карл Бергквист
Рекомендуется использовать ghostdoc ?! Га
конфигуратор