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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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