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


18

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

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


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

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

somefunction()
{
    //...
}

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

somefunction() {
    //...
}

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

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

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

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

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


6
как долго вы используете стандарт, который вы «ненавидите»? а вы используете другие стандарты "параллельно"? Я имею в виду, это может быть просто вопросом привыкания к нему? Должен признать, что раньше я ненавидел тот же стандарт, но после года, написанного исключительно таким образом, эта ненависть полностью исчезла
комнат

54
Вы пропускаете явно необходимый пробел между концом объявления функции и фигурной скобкой! Вы должны сжечь!
Пап

5
Живи с этим. Это действительно очень незначительная проблема. Будь счастлив, что это единственное, что тебя беспокоит. Если вы измените язык, вы также сможете приспособиться к новому стилю. Так что работа с ним в течение нескольких недель должна исправить это ощущение, что это «неправильно».
Шлингель

8
Used by people who come from a Microsoft IDE backgroundЭто не Microsoft, например, ядро ​​Linux и K & R используют один и тот же стиль.
Лукас

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

Ответы:


47

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

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

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


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

4
Является ли ваша кодовая база настолько нетронутой, что единственная проблема, о которой стоит спорить? - Это был бы риторический вопрос - такой кодовой базы никогда не было в истории!
MattDavey

12
Я хотел бы добавить, что Линус сходит с ума, если вы форматируете сообщения git commit «неправильно». Wired.com/wiredenterprise/2012/05/torvalds_github
Джайлс Робертс,

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

1
@GilesRoberts: Линус сходит с ума, если вы форматируете сообщения git commit «неправильно», потому что это не работает с установленным процессом проверки. Тот, который хорошо работает для проекта в течение 20 лет и привлекает сотни людей. Некоторые правила процесса гораздо важнее правил форматирования кода.
Ян Худек

66

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


5
Я думаю, он спрашивает, как ему это пережить. Что на самом деле совсем другой вопрос.
Захари Йейтс

18
Несоблюдение стандарта создает худшую проблему и раздражает всех . "Смиритесь" действительно!
Фрэнк Ширар

2
Я согласен. Вы просто должны с этим справиться.
Коди

3
Честно говоря, меня это тоже расстроило бы, но, к сожалению, правильный ответ - смириться с этим.
Sulthan

27

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

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

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

7
+1 за (3), бонусные баллы, если вы установите его в качестве крюка после подтягивания / предварительного толчка для SCM, на котором вы находитесь.
Мартин Грин

1
Инструменты для стайлинга устраняют эту проблему и заставляют людей вкладывать деньги туда, где они говорят. Если вы действительно любите фигурные скобки определенным образом, тогда вы измените конфигурацию стиля, чтобы сделать все это теплым и уютным для себя. В противном случае закрой рот можно получить кодировку.
Calphool

16

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

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

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


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

8

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

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


Да, я разрываюсь между like_this и likeThis, а также. В последнее время я склоняюсь к строчному стилю, его проще читать.
doug65536

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

1
Точно. Неважно, в какой строке находится открывающая скобка. В любом случае не имеет значения, пишете ли вы MultiWordIdentifiers или multi_word_identifiers. Независимо от того, какой стандарт использует ваша компания, следуйте ему, и через пару месяцев вам будет трудно вспомнить, что вы когда-либо хотели сделать это по-другому.
Carson63000

8

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

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

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

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


явно превосходящий ответ
Mawg говорит восстановить Monica

5

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

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

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

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

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

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

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

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

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


4

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

  • Блатс код

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

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

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

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

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

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

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

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


1
-1 Я согласен по всем пунктам, но не думаю, что какое-либо мнение по каждому из этих пунктов особенно полезно.
Калеб

4

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

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

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

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

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


«Примите участие в работе по стандартизации языка ... Имейте здравый смысл как можно быстрее завершить
Бени Чернявский-Паскин

3

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

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


2

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

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

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


1
Как указано в вопросе, вопрос на самом деле не о конкретном стандарте, поэтому ваш первый абзац не уместен.
Калеб

2

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

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

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

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

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

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

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

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


0

Живи с этим.

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

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

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



-5

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


2
-1 Суть вопроса в том, как мне преодолеть это? , но ваш совет сводится к тому, чтобы не пытаться преодолеть это, просто продолжайте делать это по-своему. Это не кажется полезным. Это также не очень практично - использование prettyprinter создает возможность побочного ущерба, то есть после преобразования в предпочитаемый вами формат и обратно многие строки могут не совпадать, даже если они означают одно и то же. Это создает много проблем людям, которые просматривают разные версии, пытаясь выяснить, что действительно изменилось.
Калеб

@Caleb - Возможно, ваш опыт использования prettyprinter отличается. Мы используем Atristic Style, и никто не жалуется на это.
Manoj R

9
Любая серьезная разработка программного обеспечения будет использовать систему контроля версий. Внесение несущественных различий вызовет проблемы и вызовет раздражение у людей, которые смотрят различия (или, что еще хуже), приведет к конфликтам при регистрации.
doug65536
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.