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

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

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

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

Стандарт является стандартом открытия фигурных скобок:

somefunction()
{
    //...
}

Вместо * явно превосходящего * (обратите внимание на шутливый / расстроенный тон):

somefunction() {
    //...
}

Мои личные аргументы против стандарта:

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

Их аргументы (и мой способ внутренне возражать им):

• Легче читать, потому что вы можете видеть, где блоки начинаются и заканчиваются сразу : я не могу понять, что хорошего в блоке, если вы не знаете, чем он принадлежит, поэтому вам придется читать задом наперед.
• Я использовал его в Microsoft IDE, и мне понравилось : Ух ... ок?
• Это в стандарте : * съеживается *

Являюсь ли я единственным, кто борется с самоуверенной позицией против определенного стандарта? Как вы справились с этим? Каково ваше мнение о том, каким должен быть этот конкретный стандарт (просто для удовольствия)?

Если вы хотите преодолеть это - была цитата Торвальдса:

Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их отношениях.

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

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

Документирован ли стандарт команды? Если это так, есть ли причины в руководстве по стилю? Честно говоря, мне пришлось смириться с этим множество раз и выполнить настоящую работу. Есть и худшие проблемы, но я чувствую, что вы все еще раздражены (кстати, я согласен с вами по стилю).

Что помогло мне пройти через это:

1. Понял, что есть реальные преимущества для одного стиля (независимо от того, что это). Или, по крайней мере, так думают многие .
2. Именно то, что вы только что сделали, напишите, почему это кажется неправильным, чтобы вы могли хорошо изложить аргумент в будущем.
3. Ради бога, используйте инструмент для укладки , он сохранит ваше здравомыслие. Resharper , CodeMaid , StyleCop , JSLint , CheckStyle , и т.д. ... даже Visual Studio сделает это за вас .
4. Пинайте задницу в этом проекте и будьте готовы к следующему, когда сможете установить стандарты.

Превосходство одного соглашения над другим * явно произвольно * .

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

Аргумент объективной читабельности в пользу * согласованности * по всей базе кода.

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

Мои собственные стандарты свирепствовали, когда я был довольно новичком в программировании (скажем, пять лет в моей карьере), было то, должны ли идентификаторы с несколькими словами быть WrittenLikeThisили written_like_this. Я даже не скажу, какой из них мне понравился, но суть в том, что через некоторое время я сменил сторону, и через какое-то время мне было все равно.

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

«Совершенно превосходный», о котором вы говорите, - это тот тип превосходства, о котором говорят люди, когда говорят о вещах, «к которым они привыкли».

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

Итак, вкратце: разберись с этим.

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

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

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

Я единственный, кто борется с упрямой позицией против определенного стандарта?

Короткий ответ: «Нет», вы не единственный. Но есть более важные вещи, о которых нужно беспокоиться. Даже в стандартах, в которые каждый вносит свой вклад, всегда будет компромисс - засвидетельствуйте некоторые аспекты, которые сделали это в C99 и C12, которые не имеют никакого смысла для меня.

Даже MISRA-C (на который я имею непосредственное влияние) содержит пункты, с которыми я лично не согласен - но я могу понять, почему другие чувствуют оправдание.

как ты справился с этим?

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

Правила обычно вводятся (в закрытой двери конюшни после того, как лошадь пробежала), чтобы решить предыдущую проблему. И если правило все еще бессмысленно, поговорите со стандартным владельцем и попытайтесь «обучить» его.

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

• Блатс код

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

• Труднее набрать

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

• Труднее читать

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

• Используется людьми из MS IDE

  Гм ..... хорошо?

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

Я единственный, кто борется с упрямой позицией против определенного стандарта?

Конечно, нет. Встречи по определению стандартов кодирования ужасны! Они тянутся часами, и участники становятся лично инвестированными в получение своих любимых (и неизменно неправильных, за исключением моих) идиосинкразий, закрепленных в стандарте. К концу никто не доволен результатом. Если что-то может быть хуже, чем встреча по стандартам кодирования, то официальные встречи по проверке кода в течение нескольких месяцев следуют определению стандарта: некоторые люди пытаются принять стандарт, а другие (намеренно или нет) игнорируют его, и вы получаете часы обратной связи, такие как: В строках 132, 142, 145, 181, 195 и 221 SillyFileConverter.cpp вы помещаете открывающую скобку в ту же строку, когда стандарт кодирования четко говорит, что она должна быть в следующей строке!

как ты справился с этим?

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

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

С такими вещами я помню Гулливера в Лилипутии. Лилипуты вели войну, которая закончилась, чтобы открыть вареное яйцо. (Оригинальный бой с прямым порядком байтов, с прямым порядком байтов).

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

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

Однако вопрос о том, как обращаться со стандартом, с которым вы не согласны, возможно, более ответственный. Я думаю, что ответ заключается в том, что там, где существуют руководящие принципы по стилю, которые согласованы и использовались, ответ заключается в том, чтобы просто улыбаться, нести это и просто заниматься этим. Учтите, что согласованность важнее. Если руководство является неточным или неправильным, может быть аргумент для изменения, но это стилистический подход, так что нет никаких аргументов, кроме личных предпочтений.

Первоначально я пришел из Java, поэтому следовал стандарту, который вы упомянули. Затем я перешел на больше C ++ и C #, где используется стиль, который вы ненавидите. Но у него нет правильного или неправильного ответа. Что более важно, так это наличие стандарта, которому следуют все. Если стандарт кодирования подобен стилистическому и не является ошибочным, то попытка доказать это просто вызовет трения в команде.

Форматер + проверка в хуке - хорошее начало. Но этого недостаточно, поскольку то, что вы пишете, не так важно, как то, на что вы смотрите весь день. В некоторых ситуациях подход режима Emacs Glasses - сохранять файлы в их стиле, но отображать ближе к вашему стилю - привлекателен.

Мой опыт работы с ней - лицо именно в этот вопрос, было написано для, CamelCapsпротив underscore_separated- был то , что он быстро стал более раздражающим , чем полезно, но в течение нескольких недель она сглаживается мой переход ( с неохотой) принятием стиля компании, а также при условии выхода направить мой гнев («ах, я ненавижу это, позвольте мне снова настроить параметры ... там, по крайней мере, я что- то сделал ») ;-)

В любом случае, режим Glasses не обрабатывает размещение фигурных скобок, вы, вероятно, не используете Emacs и не читаете код исключительно в своем редакторе :-(
Но последний пункт также является возможностью - если вы читаете код большую часть времени в В качестве отдельного инструмента вы можете взломать его для преобразования стилей, не беспокоясь о переформатировании шума в обоих направлениях - потому что он доступен только для чтения! В частности, если вы читаете код в некоторых веб-интерфейсах, используйте Greasemonkey.

Вот несколько простых идей для смягчения последствий:

• Выберите более широкий, но не очень высокий шрифт, чтобы восстановить потерянные линии экрана.

  • Используйте полноэкранный режим чаще, если это возможно.

• Установите фигурные скобки, которые будут выделены тонким цветом (и мелким шрифтом?), Делая их менее заметными, чем остальная часть кода. Отступов должно быть достаточно для чтения, особенно с пустым пространством из {строк ...

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

• Re "сложнее набрать": получить реальный редактор, настроить его для автоматического открытия новой строки при нажатии {.

Живи с этим.

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

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

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

Это стандарт:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

Большинство из тех, кто говорит «это стандарт», следуют принципу «пять обезьян».

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