Работа с коллегами, у которых нет единого стиля кодирования?

30

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

  • Сочетание различных соглашений и названий имен ( underscore_styleи, camelCaseи, UpperCamelи CAPSвсе, более или менее произвольно применяемых к разным переменным в одной и той же функции)
  • Необычные и непоследовательные интервалы, например Functioncall (arg1 ,arg2,arg3 );
  • Много слов с ошибками в комментариях и именах переменных

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

Как бы вы посоветовали этому человеку быть более внимательным и соответствовать таким деталям?

JSB ձոգչ
источник
2
"Красивые принтеры" помогают. Кроме того, у вашей фирмы есть руководство по стилю?
chrisaycock
1
как насчет коллег, у которых нет грамматики? ;)
Muad'Dib
4
@JSBangs: установите проверку стиля перед коммитом и откажитесь от коммитов. Это заставит их быстро и правильно отформатировать. Или попросите хук pre-commit для вас выполнить форматирование. Некоторые вещи будут выглядеть, но это лучше, чем странно, лучше, чем "ужасно", я думаю.
Хайлем
3
Еще одна мысль - это может показаться мелочным, но его мелочность для цели (при условии, что а) существует стандарт кодирования и б) все остальные согласны и придерживаются его)
Мерф
3
Каково прошлое этого программиста? Похоже, он работал на слишком много разных компаний со слишком многими различными соглашениями о форматировании кода, и его мозг превратил их всех в беспорядочный беспорядок. :-)
Carson63000

Ответы:

19

Согласиться на соглашение о кодировании

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

Темная ночь
источник
1
Абсолютно - тогда а) каждый пытается достичь одного и того же стандарта и знает, что это такое; б) ваш отказ при проверке кода может быть уменьшен до «не соответствует стандартам кодирования» (по крайней мере, если файл в целом является беспорядок - если это всего лишь одна или две вещи, вам нужно быть конкретным)
Мерф
Обычно я никогда не видел, чтобы команда умудрилась за один час «договориться» о полномасштабном соглашении по кодированию для любого языка :) Но если под соглашением вы подразумеваете «обсудить до разногласия, а затем навязать по званию и авторитету», то это работает. Вы должны опустить ногу в некоторых моментах, потому что вы не найдете консенсуса, или вам очень повезло с вашей командой.
Хайлем
28

Я думаю, что вы просто должны продолжать делать то, что вы делаете. Иметь четкий набор рекомендаций по кодированию и применять их при проверках кода. Если разработчик получает 50 или 100 строк «Добавить пробел здесь» и «Заклинание« итератор »правильно» каждый раз, когда он пытается что-то проверить, и ему на самом деле не разрешают регистрироваться до того, как все это исправят, в конце концов он Придется начать писать более чистый код, чтобы избежать хлопот.

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

Дима
источник
5

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

Для профессии, где ваш синтаксис должен быть на 100% корректным для работы, у любого реального разработчика просто нет оправдания отсутствию чистого, согласованного стиля кода. Все остальное - неряшливость и лень. Я всегда подвергаю сомнению правильность отформатированного кода в реализации.

жёстко
источник
4

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

Я бы изменил это сам, а затем добавил в код вежливый комментарий.

это предполагает, что уже есть руководство по стилю, поскольку вопрос задан:

У нас хорошая система проверки кода

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

ним чимпский
источник
10
Это стареет довольно быстро.
Роберт Харви
3
Возможно, это быстрее для вас, чем отправка электронного письма, и в целом быстрее для решения проблемы, но это медленнее, чем если бы проблема не возникла в первую очередь.
Хайлем
4

Я думаю, что такие соглашения, как присвоение имен классам и переменным, важны, и их следует придерживаться, элегантный и эффективный код, но рискуя многократно опровергнуть мой ответ, я должен сказать, что в целом парадигма «красивого кода», которая много толкается в ИМХО очень переоценен.

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

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

Jas
источник
Что вы скажете о коде, подобном следующему: stackoverflow.com/questions/6221098/save-mapview-as-a-bitmap/… Вы все еще думаете, что программист, который имеет дело с этим "стилем", является плохим программистом, если он есть серьезные проблемы с этим?
WarrenFaith
@WarrenFaith, возможно, вы захотите вернуться к моему 3-му абзацу, в частности к этому фрагменту здесь: «Пожалуйста, обратите внимание, что я не поддерживаю кодирование в стиле спагетти / ковбойского стиля здесь ...».
Jas
3

Один из моих коллег пишет html таким образом, что он заставляет мою кожу ползти. Вообразите мой HTML красивым и структурированным с двумя пробелами, разбитыми на куски с помощью тегов, добавленных к моему концу, которые заканчиваются на одной и той же строке или на следующей, как какой-то пьяный, который должен обнять вас, чтобы оставаться на ногах. Новые линии редко имеют отступы, но если они есть, я уверен, что в какой-то части галактики есть какая-то очень хаотичная черная дыра, выплевывающая иррациональные значения температуры таким образом, что ее цифры каким-то образом отражают количество пробелов или табуляций, используемых в таком отступе. этой женщиной. Если мне повезет, я увижу входной тег, закрытый знаком " </input>". Общий кошмар, который вы можете понять.

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

Нил
источник
3

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

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

jjnguy
источник
3
Программисты тратят больше времени на чтение кода, чем на написание кода. Если код не читается, стоимость его расширения или поддержки становится огромной. И если имена переменных являются непоследовательными, написанными с ошибками и не описательными, это делает код нечитаемым.
Дима
@ Дима, правда, но тот код, который работает и изящен, уже легче читать, чем код, который сломан и не элегантен.
jjnguy
1
Моя точка зрения заключается в том, что вы должны иметь возможность посмотреть имя переменной, имя класса или имя функции и сразу же знать, как его использовать, не просматривая всю базу кода. Вы также должны быть в состоянии напечатать имя в соответствии с соглашениями и понять его правильно, без необходимости искать его. Я рекомендую вам прочитать «Чистый код» Роберта С. Мартина.
Дима
@Dima, я согласен, что переменные должны иметь описательные имена. ОП не упоминает, что имена плохие, просто они противоречивы.
jjnguy
1
По моему опыту, когда имена противоречивы, они, как правило, не описательны. Но есть и другая проблема. Когда имена противоречивы, вам нужно больше времени, чтобы вспомнить, какие они есть, и вам приходится тратить время на их поиск. Хорошая IDE может помочь, но это не решит проблему полностью. Программирование уже возлагает достаточную нагрузку на ваш мозг, поэтому вы хотите максимально сократить количество умственного картирования и двойной проверки.
Дима
2

Похоже, вам нужно настроить и принять соглашение о стиле. Если у вас нет, у вас будут библиотеки с 3 отступами, другие с 4, некоторые с использованием Camel Case, а другие с underscore_case.

Wheaties
источник
2

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

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

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

HLGEM
источник
2

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

Вот что должно стимулировать:

  1. Проверка кода будет утомительной и дольше, чем необходимо.
  2. Код будет отклоняться чаще.
  3. Графики не будут соблюдены.

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

JeffO
источник
2

Я хотел бы предложить приватный чат и посмотреть, сможете ли вы оба найти причину:

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

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

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

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

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

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

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

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

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

JB King
источник
2

У нас есть тест JUnit, который ищет проблемы с форматированием. Он работает как часть сборки. Я постоянно получаю немного, опуская пробел между if, while или for и открывающей скобкой. Однако наш код постоянно отформатирован.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

Кевин Петерсон
источник
1

Усовершенствование кода, например unscrutify, поможет решить некоторые ваши проблемы. Если вы готовы заплатить за это, то есть программное обеспечение высокого уровня, которое встраивает правила в сам исходный код, например, Parasoft . Parasoft делает обязательным написание кода в едином стиле. Вы также можете встраивать свои собственные правила. Когда такие инструменты используются, разработчики вынуждены использовать единый стиль. И через некоторое время они к этому привыкнут.

Маной Р
источник
1

Если вы используете Eclipse, включите «Сохранить действия для редакторов Java» и попросите всех использовать его. Это исправляет проблемы форматирования при каждом сохранении, но не исправляет неправильную капитализацию. Это может быть очень полезно, хотя!

альтернативный текст


источник
1

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

davidk01
источник
0

СМЕШНО. Вы бы абсолютно ненавидели мой код. Я не могу записать, чтобы спасти мою жизнь, и мне все равно.

Но я знаю, что некоторые люди действительно заботятся об этих вещах.

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

обычно технически корректен, разумно структурирован и может даже быть алгоритмически элегантным

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

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

ElGringoGrande
источник
5
Если имена ваших переменных написаны с ошибками, следующему парню, который использует ваш код, придется потратить дополнительное время на исправление ошибок компилятора, когда он правильно их записал. Это не о "тонких чувствах". Эти, казалось бы, тривиальные вещи вызывают ошибки, которые вызывают разочарование, которое вызывает больше ошибок. Все это приводит к огромным затратам на обслуживание кода.
Дима
4
Это немного больше, чем «деликатная чувствительность», но продуктивность. Я не возражаю против кого-то с немного отличающимися стилями кодирования, иногда забывая пробел и т. Д. Но когда весь файл выглядит так, как будто он записан старшекурсником, с / с непоследовательным межстрочным интервалом, позициями, отступами и общим потоком кода, тогда я просто очень быстро нажму кнопку «отклонить» (или вернуться).
Хайлем
2
Многие успешные проекты с открытым исходным кодом (включая linux) делают это: если у вас нет подходящего стиля (и модульных тестов), тогда он отклоняется. Жаль, если это было хорошо и решило реальную проблему: вы не всегда можете исправить чужой код. В целом, вы теряете меньше времени и денег, просто передавая случайную часть гения, которая проходит через, но выглядит как ад или не поддерживается.
Хайлем
1
Прикольные вещи. Но, конечно, главное, кажется, упущено. Сначала вы получаете парня с очевидными вещами, за которые вы можете сделать веские аргументы. Тогда вы работаете над менее важными вещами. Есть способы работать с людьми за пределами просто задушить их правилами. И, может быть, просто может быть, толпа OCD могла бы немного пойти на компромисс или узнать, почему в другом коде так много различий. Там может быть причина или причина.
ElGringoGrande
0

Мое решение при работе с внешними ресурсами, которые не давали &% $ # о форматировании (или легко предотвратимые ошибки в этом отношении), состояло в том, чтобы заставить сервер сборки применять это. Я создал задание сервера CI, которое выполнялось каждую ночь, проверяя код, запускал Jalopy и findbugs, а затем проверял код обратно. Как только другая команда узнала, что неиспользование стандартных соглашений о коде усложнит их работу, они начали использовать свои IDE для поддержания стандартного формата.

Сэл
источник