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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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