Что самое странное кодировало правило стандарта, что Вы были вынуждены следовать? [закрытый]

Мы должны поместить комментарий выше каждого sql оператора. Так, у Вас может быть sql оператор как таковой

Избранный USER_ID ОТ ПОЛЬЗОВАТЕЛЕЙ ГДЕ ИМЯ =: ИМЯ;

И у Вас все еще должен быть комментарий выше его, в котором было бы сказано:

Избранный USER_ID от таблицы USERS, где имя равняется введенному имени.

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

Это было на мэйнфрейме, кодирующем в Коболе. Размер команды обычно - приблизительно 4 или 5, но это правило кусало всех здесь время от времени.

В Дельфи мы должны были измениться от

if something then
begin
  ...
end
else
begin
 ...
end;

к

if something then begin
  ...
end else begin
 ...
end;

в проекте с 1,5 миллионами строк кода. Вообразите, насколько легкий это было на управлении исходным кодом, разности и слиянии! Это также привело к упущению, начинаются и не замечающий его сразу же, когда компилятор объявил о лишнем конце.

Добавление 80 символьных комментариев в конце каждого метода, таким образом, легко найти конец метода. Как это:

void doSomething()
{
}
//----------------------------------------------------------------------------

объяснение, являющееся этим:

• некоторые пользователи не используют IDE, которые имеют сворачивание кода (Хорошо, я дам им это).
• пространство между методами не ясно, так как люди не могут следовать другим стандартам кодирования о расположении с отступом и заключить в фигурные скобки размещение, следовательно было бы трудно найти конец функции. (Не releavent; если необходимо добавить это, потому что люди не следуют стандарту кодирования тогда, почему они должны следовать за этим?)

вставка разрывов строки
(//--------------------------------------------------------------------------------)
между методами в c# проекте.

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

Другой - возможно, самый сумасшедший из всех, но возможно не стандарт кодирования...

никакой STL не позволяется. и это было в 2007/2008. Я уехал там вскоре после того, как я узнал о той ерунде. По-видимому, некоторые идиоты думали, что не было никакого "стандарта" (Как в 15 лет назад...), я предполагаю, что они пропустили записку о stl, находящемся в стандарте C++...

Использование глупого COM HRESULTs как возврат вводит для примерно ВСЕХ методов - даже если они не COM. Это было смехотворно. Таким образом, теперь вместо того, чтобы возвратить некоторый перечислимый тип или полезное значение, которое указывает на результат, и т.д., мы должны были искать what's_OK или E_FAIL или, независимо от того, что предназначено в контексте каждого из методов. Снова, я уехал там вскоре после этого.

Я работал в месте, где стандартом кодирования был один гигантский WTF: странная Венгерская запись, снабжая префиксом globals с 'g' и участниками с 'm' (таким образом, были драгоценные камни как gsSomeVariable), добавляя 'касательно строки sError' к каждой функции, вместо того, чтобы выдать исключения (который был БОЛЬШИМ nono!).

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

я работаю теперь в намного лучшем месте:)

Я когда-то должен был обстоятельно объяснить все акронимы, даже промышленного стандарта, такие как OpenGL. Имена переменной, такие как glu не были хороши, но мы должны были использовать graphicsLibraryUtility.

Мне сказали, что старый код должен быть прокомментирован вместо того, чтобы быть удаленным; в случае, если мы должны были обратиться к старому коду (да, код был в управлении исходным кодом...). Это не кажется, что плохо, пока существенные изменения не внесены. Тогда это становится кошмаром со всеми разделами, удаленными на всем протяжении кода.

Тот, который получил меня, был подобен "tbl" префиксу другого плаката для имен таблиц SQL.

В этом случае, префикс для всех хранимых процедур должен был быть "SP _" несмотря на то, что "SP _" является префиксом, используемым Microsoft для хранимых процедур системного уровня в SQL Server. Ну, они имели свои стандарты от старой, базы данных неMS и не собирались измениться просто, потому что их стандарт мог бы заставить хранимую процедуру сталкиваться с системной хранимой процедурой и приводить к непредсказуемым результатам. Нет, это просто не было бы надлежащим.

Тот, который никто не упомянул, вынуждается записать модульные тесты на классы, которые являются глупыми методами get и методами set.

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

В нашем C кодируют, мы были обязаны префикс все точки с запятой с пространством

int someInt = 5 ;

, я никогда не мог узнавать причину этого, но через некоторое время это действительно росло на мне.

Если я помню правильно, что IDE Дельфи сделал отступ по умолчанию двух пробелов. Большая часть унаследованного кода для компании имела три пробелов и была записана IT VP и генеральным директором. Однажды, все программисты говорили о том, что мы должны сделать для создания наших жизней легче и подрядчик, который знал, что Дельфи вполне прилично заявил, "Эй значения по умолчанию язя к двум пробелам у кого-либо есть проблема с нами делающий это продвижение для нового кода?" Все мы посмотрели друг на друга, и в значительной степени думали, что это не было никаким brainer и сказало, что мы согласились.

Два дня спустя VP и генеральный директор узнали, что мы собирались внести такое опасное изменение, которое могло "вызвать проблемы" и сообщило нам, что мы будем использовать три отступа для всего, пока два из них не могли точно оценить влияние такого изменения. Теперь я - все для следующих стандартов, но это те же люди, которые думали, что программирование oo создавало объект с одной функцией, которая имела весь из логики, необходимой для выполнения действия, и что управление исходным кодом перемещало файлы кода в различный каталог.

Это был стандарт кодирования, за которым я не следовал сам (вошел в проблему другим вещам, но никогда этому). У нас было три 19-дюймовых монитора, таким образом, мы могли иметь двух редакторов, открытых для полного экрана, и все еще иметь доступ к рабочему столу. Все остальные не использовали комментарии, но использовали понятные имена. Чрезвычайно длинные понятные имена. Самое длинное, которое я помню, было в 80 диапазонах символов. Среднее число было приблизительно 40~50.

Предположение, что, они точно не описали все это.

(Вероятно, только забавный в Великобритании)

страховщик я работал в требуемом комбинация "P" или "L" для обозначения объема, связанного с венгерским языком для типа, на всех свойствах.

плюс был, у нас было свойство, названное pintMaster! Сделанный нами всеми представить себе напиток.

Размер команды был приблизительно дюжиной. Для методов C# мы должны были поместить огромный XML отформатированная функция перед каждой функцией. Я не помню формат точно, но он включил XML-тэги, вложенные приблизительно три - пять уровней глубоко. Вот эскиз из памяти комментария.

/// <comment>
/// </comment>
/// <table>
///    <thead>
///       <tcolumns>
///          <column>Date</column>
///          <column>Modified By</column>
///          <column>Comment</column>
///       </tcolumns>
///    </thead>
///    <rows>
///       <row>
///          <column>10/10/2006</column>
///          <column>Fred</column>
///          <column>Created function</column>
///       </row>
///    </rows>
/// <parameters>

я должен остановиться там....

оборотные стороны были многими.

• Файлы были составлены главным образом комментариев.
• Мы не использовали нашу систему управления версиями для отслеживания изменений в файлах.
• Запись многих небольших функций повредила удобочитаемость.
• Партии прокрутки.
• Некоторые люди не обновили комментарии.

я использовал фрагмент кода (Emacs YAS) для добавления этого кода к моим методам.

Применение s_ к переменным и методам, которые считали "безопасностью, очень важной" для программного обеспечения, которое было частью системы управления. Свяжите это с другим правилом о помещении m_ на передней стороне членских переменных, и Вы получили бы что-то смешное как "s_m_blah ()", который является проклятым раздражением для записи и не очень читаемый, по-моему. В конце некоторый 'эксперт по безопасности', как предполагалось, вникал путем рассмотрения кода и определения чего-то от него при помощи тех "s _" - на практике, они не знали C++ слишком хорошо, таким образом, они не могли сделать многого кроме, делают отчеты о количестве идентификаторов, что мы отметили как 'очень важную безопасность'. Чрезвычайная ерунда...

Самый странный, который я видел, был именованием таблицы базы данных, где таблицы были снабжены предисловием с TLA для функциональной области, например, считающий ACC тогда 3 числа цифры к (сверхъязь сортировка по умолчанию) и затем имя таблицы.

Плюс это был расширен в имена столбцов также.

ACC100_AccountCode

это был кошмар для чтения запроса, они были таким образом нечитабельны.

Необходимо использовать только пять имен таблиц буквы, и последние два символа резервируются для IO.

То, что сводит меня с ума, является людьми, снабжающими суффиксом поле ID таблицы с названием таблицы. Что, черт возьми, является неправильным только с идентификатором? Вы оказываетесь перед необходимостью искажать его так или иначе... из любви ко всему, что священно!

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

Каждое начало и окончание фигурной скобки были , потребовал иметь комментарий:

public void HelloWorld(string name)
{

  if(name == "Joe")
  {
    Console.WriteLine("Hey, Joe!");
  } //if(name == "Joe")
  else
  {
    Console.WriteLine("Hello, " + name);
  } //if(name == "Joe")
} //public void HelloWorld(string name)

Это - то, что привело меня писать свой первый плагин Visual Studio для автоматизации этого.

Несколько WTF's в одном магазине VB6 (я не горд, я был голоден и необходим для еды), назад в 2002 - 2004.

самое раздражающее, по моему скромному мнению, устанавливал все ссылки на объект ни на что в конце sub/function. Это должно было "помочь" количеству справочника по компилятору. Не имело значения, сколько тестов я выполнил для TA, чтобы доказать, что это не было необходимо, О нет, это все еще должно было быть сделано, даже при том, что у него был absoutely никакое доказательство для поддержки его что поэтому когда-либо . В конечном счете я сдался и приблизительно год спустя нашел статью, объясняющую, почему это были штаны. Я приношу, это к взглядам TA "Получило fecker!". Он идет "Да, я знал об этом в течение многих лет, но если Вы начнете изменять стандарт овцы" значение других разработчиков, то люди, он работал с повседневным, "завинтят его". Рот sh1te.

Другие в том же магазине.

• Никогда не удаляют код, всегда комментируют его (даже при том, что мы использовали управление исходным кодом).
• Префиксы на именах таблиц, которые были бессмысленны, когда я добрался там, но должен был быть осуществлен на новых таблицах.
• Добавление префикса всех объектов с o_ (lo_ для ссылок уровня процедуры, mo_ для модуля, go_ для глобального). Absoutely, бессмысленный в проекте, где любая переменная была ссылкой на объект.

Главным образом я писал C++ там (только разработчик C++, таким образом, сделанный собственными стандартами, и осуществленный с суровостью!) со случайным vb иначе я не продержался бы.

Таблицы префиксов с dbo _

Да, как в dbo.dbo_tablename.

Мой самый странный был в контракте парой несколько лет назад. странный @ZombieSheep был частью его, но не самой странной в той компании.

нет, самый странный в той компании был схемой именования базы данных. Каждую таблицу назвали всеми заглавными буквами с подчеркиваниями между словами. Каждая таблица имела префикс (обычно 1 - 6 символов), который обычно был акронимом или сокращением основного имени таблицы. Каждое поле таблицы было снабжено префиксом тот же префикс также. Так, скажем, у Вас есть простая схема, где люди могут владеть кошками или собаками. Это было бы похоже на это:

PER_PERSON
    PER_ID
    PER_NameFirst
    PER_NameLast
    ...
CAT_CAT
    CAT_ID
    CAT_Name
    CAT_Breed
    ...
DOG_DOG
    DOG_ID
    DOG_Name
    DOG_Breed
    ...
PERCD_PERSON_CAT_DOG (for the join data)
    PERCD_ID
    PERCD_PER_ID
    PERCD_CAT_ID
    PERCD_DOG_ID

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

Heck, через некоторое время, все мы в команде (6 человек на нашем проекте) смогли начать обращаться к таблицам в разговоре не чем иным как префиксом. На любителя, чтобы быть уверенным... Но тот, который вырос на мне. Так так, чтобы я все еще использую его, когда я имею что свобода.

Быть вынужденным иметь только 1 оператор возврата в конце метода и того, чтобы заставлять код падать к этому.

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

Наконец, когда я начал использовать C, я нашел его очень нечетным для объявления моих переменных наверху метода и абсолютно ненавидел его. Я потратил хорошие несколько годы в C++ и просто объявил их везде, где я хотел; Если для оптимизации не обосновывает, что я теперь объявляю все переменные метода наверху метода с деталями того, что они все делают - делает обслуживание НАМНОГО легче.

В Java при заключении контрактов где-то, что должно остаться безымянным, интерфейсы были запрещены. Логика? Ответственный парень не мог найти реализующие классы с помощью Eclipse ...

Также запрещены - анонимные внутренние классы на том основании, что ответственный парень не знал, кто они. Благодаря чему реализация Swing GUI доставляла массу удовольствия.

Вау - это возвращает столько воспоминаний об одном конкретном месте, что Я работал: Департамент транспорта Аризоны.

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

(Серьезно - на самом деле она провела большую часть своего дня, проверяя код, который мы зарегистрировали в Visual SourceSafe, чтобы убедиться, что мы не нарушаем правила).

Учитывая, что Visual Basic 4 только что был выпущен (это было около 12 лет назад), и учитывая, что приложение форм Windows, которое мы создавали на VB4 , использовало объекты для описания форм , это привело к разработке ... сложно.

Мой приятель на самом деле пытался обойти эту проблему, инкапсулируя свой «объектный код» внутри фиктивных «форм», и в конце концов она поняла, что он просто (* вздох *) скрывал свои объекты!

Излишне говорить, что я продержался там всего около 3 месяцев.

Черт возьми, мне не нравились мысли этой женщины.

Учитывая, что Visual Basic 4 только что был выпущен (это было около 12 лет назад), и учитывая, что приложение форм Windows, которое мы создавали на VB4 , использовало объекты для описания форм , это привело к разработке ... сложно.

Мой приятель на самом деле пытался обойти эту проблему, инкапсулируя свой «объектный код» внутри фиктивных «форм», и в конце концов она поняла, что он просто (* вздох *) скрывал свои объекты!

Излишне говорить, что я продержался там всего около 3 месяцев.

Черт возьми, мне не нравились мысли этой женщины.

Учитывая, что Visual Basic 4 только что был выпущен (это было около 12 лет назад), и учитывая, что приложение форм Windows, которое мы создавали на VB4 , использовало объекты для описания форм , это привело к разработке ... сложно.

Мой приятель на самом деле пытался обойти эту проблему, инкапсулируя свой «объектный код» внутри фиктивных «форм», и в конце концов она поняла, что он просто (* вздох *) скрывал свои объекты!

Излишне говорить, что я продержался там всего около 3 месяцев.

Черт возьми, мне не нравились мысли этой женщины.

Мой приятель на самом деле пытался обойти эту проблему, инкапсулируя свой «объектный код» внутри фиктивных «форм», и в конце концов она поняла, что он просто (* вздох *) скрывал свои объекты!

Излишне говорить, что я продержался там всего около 3 месяцев.

Черт возьми, мне не нравились мысли этой женщины.

Мой приятель на самом деле пытался обойти эту проблему, инкапсулируя свой «объектный код» внутри фиктивных «форм», и в конце концов она поняла, что он просто (* вздох *) скрывал свои объекты!

Излишне говорить, что я продержался там всего около 3 месяцев.

Черт возьми, мне не нравились мысли этой женщины.

Я когда-то работал над проектом VB.NET, где каждый метод тела был завернутый в следующие Блок ... Catch :

Public Sub MyMethod()
    Try
        ' Whatever
    Catch Ex As Exception
        Throw New Exception("MyClass::MyMethod::" + Ex.ToString())
    End Try
End Sub

Те, кто не понимает Exception.Stacktrace обречены, чтобы восстановить его, плохо.

Однажды мне пришлось сделать небольшую DLL вне моей команды, и когда это было сделано, мне пришлось переделать работу, потому что я не должен был использовать "else" в коде. Когда я спросил, почему Меня проинструктировали не спрашивать почему, но лидер другой команды просто «не получил ничего другого».

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

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

Итак, в системе, которая вполне могла бы иметь таблицу «клиентов» под названием «ThisIsTheCustomerTable», вместо этого она называлась «TBRC03AA». Следующая таблица называлась «TBRC03AB», следующая - «TBRC03AC», и так далее.

Это сделало SQL действительно легким для понимания, особенно через месяц после того, как вы его написали.

Я completly не соглашаются с этим, но я был вынужден следовать за ним:

"Все ССЫЛКИ HTML будут ВСЕГДА подчеркиваться".

Некоторое время назад я объяснил, почему я не соглашаюсь на моем блог .

Примечание: Даже Stackoverflow ТОЛЬКО подчеркивает ссылки при перемещении мыши через них.