Насколько важен хороший стиль кодирования для решения нанять программиста? [закрыто]

15

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

В то время как я очень строг в стиле кодирования, я только что прочитал о «блочном» стиле, который кто-то использовал (читайте комментарии!) .

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

В поисках стиля кодирования и того, как справиться с его отсутствием, мне любопытно одно: должен ли я нанять парня, который будет иметьсерьезная проблема адаптировать стиль кодирования, используемый в фирме?

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

Дополнительная информация:

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

WarrenFaith
источник
9
Умная. Вместо того, чтобы устранять «серьезные проблемы с адаптацией» (что не подтверждается фактами), проведите линию через это. Как будто это на самом деле меняет безосновательное утверждение о чьем-либо отношении.
S.Lott
2
Стиль кодирования - наименее важная вещь, с которой вам следует столкнуться. В конце концов, это всего лишь код.
SK-logic
7
Я пытался прочитать твой вопрос, но нашел, что твое форматирование трудно понять. Не могли бы вы добавить начальный отступ к своим абзацам. 'K THX BAI
dietbuddha
2
Согласованность кода (или его отсутствие) является показателем. Например, если у кого-то нет времени на организацию своего кода, у него, вероятно, также нет времени, чтобы найти правильное место для фиксации нового проекта в Subversion. У них, вероятно, нет времени на рефакторинг. Список можно продолжить.
Кевин
10
Стиль кодирования смехотворно прост в настройке. Это все равно что спросить: «Этот человек носит черные костюмы, но в нашей компании мы предпочитаем, чтобы сотрудники носили темно-серые костюмы. Должен ли я их нанять?» Просто скажите им, какие правила стиля у вас в компании. Проблема решена.
сочная Люси

Ответы:

41

Откуда вы знаете, что у него (-ов) будут проблемы с адаптацией? Просто потому, что они используют другой стиль кодирования? Это довольно самонадеянно. Я был подрядчиком в течение долгого времени, и независимо от того, какой стиль кодирования используется, вы адаптируетесь. Это может занять некоторое время, но привычки формируются довольно быстро.

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

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

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

Марьян Венема
источник
5
+1 не иметь или не использовать его постоянно - это «красные флажки», а другой стиль - нет.
jv42
1
Я полностью согласен с «по крайней мере, использовать его последовательно». Это самое главное, когда я проверяю код. Но вы должны признать, что стиль кода / формат кода - это самое первое впечатление, которое вы получаете, когда смотрите на иностранный код ...
WarrenFaith
3
@WarrenFaith: так ты судишь о книге по ее обложке? :-) Если серьезно, да, это действительно производит первое впечатление, но я предполагаю, что при проведении собеседования вы позаботитесь о том, чтобы выйти за рамки этого и не упустить идеально способного разработчика только потому, что его текущий стиль не соответствует вашему.
Марьян Венема
+1 за последовательность: отсутствие стиля обычно означает, что они мало что написали. Когда ты пишешь, ты выбираешь привычки.
Матье М.
1
Я ненавижу автоматические средства форматирования кода, но я могу принять потребность в них. Кажется, они просто выбирают разрывы строк во всех неправильных местах. Да, я говорю о затмении.
Кевин
27

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

Стиль кодирования (и спор о стиле кодирования) - пустая трата времени.

Преодолей это.

Я прочитал много кода от разных программистов. (Допустим, средний размер команды 5 и 100 разных команд. Это 500 сотрудников.) Стиль не имеет значения.

Я видел красивый, но патологически неправильный код.

[Есть предел. Умышленное запутывание является основанием для прекращения. Если не считать этого, стиль - пустая трата времени.]

Стиль кодирования - это «последний рубеж»

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

Когда нечего исправить, вы, наконец, можете сосредоточиться на стиле кодирования.

До тех пор существует множество вопросов, которые больше и ценнее, чем стиль.

С. Лотт
источник
2
@WarrenFaith: я не могу сказать это достаточно сильно. Это неважно. Я повторю свою точку зрения. Я прочитал (профессионально, за плату, оплачиваемые часы) код от сотен и сотен программистов. Это неважно. Это не первое впечатление: правильность и ясность - первые впечатления.
С.Лотт
2
@WarrenFaith: преднамеренная неясность встречается редко. «Если вы просто не можете прочитать код», это может быть такой же проблемой для читателя, как и для автора. Я повторю свою точку зрения. Я прочитал (профессионально, за плату, оплачиваемые часы) код от сотен и сотен программистов. «Просто не умею читать» никогда не было. Стиль не имеет значения.
С.Лотт
2
Стиль кодирования (и спор о стиле кодирования) - пустая трата времени. - Я согласен на 100% по второму пункту и около 40% по первому. Стиль кодирования имеет значение - если в вашем кодировании вообще нет стиля. Если есть, то не так важно, как это выглядит.
Треб
4
@WarrenFaith: я посмотрел на образец и не вижу там ничего непонятного. Это не отформатировано, как я мог бы отформатировать это, но там нет ничего, что указывает на то, что код не будет работать. В этом нет ничего неясного. Ничто не говорит о том, что человек, который написал, не сможет или не захочет соответствовать стандарту команды. @ С. Лотт прав. Это не важно
Джоэл Этертон
4
И использовать //Importantна каждой строке. Гм. Каждая строка кода важна или должна быть удалена.
С.Лотт
7

Оценка программистов по стилю кодирования - это 50% снобизма и 50% небезопасности.

Мне нравится, что мой код выглядит аккуратным и чистым, и похоже, что парень, которого опрятал в ссылке, тоже делает. Наш код не выглядит одинаково, но мы оба используем стиль, который помогает нам понять код, когда мы возвращаемся к нему. У меня не было абсолютно никаких проблем с пониманием его кода, и я сомневаюсь, что OP тоже. «Совет» в стиле кодирования - это просто дешевый снимок, где вы можете передать свою огромную мудрость о том, почему фигурные скобки должны быть на следующей строке. Это не имеет значения вообще. Что делает код трудным для чтения, так это:

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

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

Морган Херлокер
источник
7

Это смешно иметь формат кода быть фактором при принятии решения , чтобы нанять кого - то.

  1. Есть много более важных факторов для рассмотрения.
  2. Большинство разработчиков могут адаптировать свой стиль.
  3. Если формат очень важен, используйте средство переформатирования кода и средство проверки содержимого.

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

dietbuddha
источник
4

Я полагаю, у вас есть официальный стиль форматирования в компании.

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

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


источник
забыли проблемы с фиксацией ... и да, у нас есть официальный стиль форматирования, а также автоматическое форматирование перед сохранением.
WarrenFaith
@ Уоррен, ну, тогда скажи это на собеседовании и убедись, что программист понимает, что это важно. Тогда он должен выполнить свое обещание, если он хочет сохранить работу.
4

Используйте StyleCop

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

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

CVS интегрированное форматирование кода = оптимальное решение

Было бы здорово, если бы любой из CVS поддерживал автоматическое форматирование кода при регистрации. Вы просто устанавливаете свои приоритеты стиля, код будет отформатирован перед сохранением. Это сделало бы определенный стиль разработчика устаревшим с точки зрения форматирования кода. Я вижу проблему, если некоторые разработчики используют разные символы отступа. Мне не так сложно смотреть на другой код (и я могу легко и быстро его переформатировать), но с DIFF становится все труднее справиться. Много ложных срабатываний в инструменте DIFF.

Роберт Коритник
источник
Итак ... если какая-то компания изобрела свои собственные стандарты кодирования C #, это будет красный флаг?
Работа
1
@Job: не обязательно, потому что StyleCop позволяет добавлять дополнительные правила. Я знаю, что написал два из них, которые применяли TAB над SPACE, которых не было в первую очередь. Но идея заключается в том, что стиль кодирования можно использовать принудительно, что значительно облегчит создание единого кода.
Роберт Коритник
Что если их стиль снова станет таким же, как у StyleCop, и если они вообще не будут использовать StyleCop - будет ли это тогда?
Работа
@Job. Если кто-то не пишет код C # так, как если бы это был старый Фортран (кто-нибудь с фиксированным макетом в 80 столбцов?), Я все же думаю, что стиль кодирования можно попросить соблюдать. Если кто-то является отличным разработчиком, вы можете напомнить ему об улучшении своего стиля (или позволить ему оправдать свой стиль над нашим ). Вот для чего нужен обзор кода. Любой код может быть быстро переформатирован, но должны соблюдаться как минимум соглашения об именах. Но это ни в коем случае не красный флаг на прокат. Не должно быть
Роберт Коритник
3

Намного ниже следующие гораздо более важные детали:

  • Team Fit
  • Способность решать проблемы
  • связь

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

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

прецизионный самописец
источник
В моем случае это часто единственное, что я вижу от парня ...
WarrenFaith
@WarrenFaith - Хорошо, но вы никогда не примете решение одной рукой нанять кого-нибудь, основываясь на столь малой информации, не так ли? Вас просто спрашивают о мнении.
PDR
Правда. Я высказываю свое мнение с технической точки зрения, и мягкие навыки также важны. И мы тестируем только тех ребят, которые хотя бы прошли «тест» на мягкие навыки в интервью. Но мне любопытно, какое влияние стиль кодирования должен оказать на мое мнение ...
WarrenFaith
@WarrenFaith - на вашем месте я бы это упомянул, но скорее как личность, а не как нечто огромное значение.
PDR
Я просто делаю список за и против и объясняю и оправдываю его для нашего технического директора. Окончательное решение остается за ним ...
WarrenFaith
3

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

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

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

Виктор Хурдугачи
источник
0

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

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

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

(И да, я зависим от кофеина.)

треб
источник
Проблема, связанная с «плохим стилем кодирования», часто заключается в неопытности. Когда я вижу большинство начинающих, им часто не хватает того, что можно назвать стилем кодирования.
WarrenFaith
?? "сильный аргумент против этого человека" ... "на самом деле не стоит беспокоиться о стиле кодирования". Что он? Имеет ли это значение или нет? Сложно сказать из ответа, какой у вас совет. Не могли бы вы уточнить, пожалуйста?
С.Лотт
@ S.Lott: что это? - Ну, конечно оба. Плохой стиль кодирования - плохая привычка, большинство людей могут научиться избавляться от него. Это когда они не могут (или не хотят) узнать, что у вас есть проблема.
Треб
0

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

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

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

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

florianb
источник