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

Ще як студент мене просять переглянути код програмістів, які (не) пройшли тест (створити список номерів Фібоначчі на android).

Хоча я дуже суворий щодо стилю кодування, я просто читав про "блоковий" стиль, який хтось використовував (читайте коментарі!) .

На моєму становищі я рекомендував би не наймати хлопця, який використовує такий стиль. Код абсолютно протилежний стилю кодування, який використовується в моїй фірмі.

Під час пошуку стилю кодування та способів боротьби з його нестачею мені цікаво одне: чи найняти хлопця, який матимесерйозні неприємності адаптація стилю кодування, що використовується у фірмі?

Будь ласка: це не повинно бути дискусією про стиль кодування взагалі, а що краще. Це про важливість стилю кодування для рішення когось найняти!

Більше інформації:

Я не той хлопець, який приймає рішення, я просто висловлюю свою думку на основі коду. Хлопець повинен пройти співбесіду, де наш керівник все-таки перевіряє м'які навички. Якщо він пройшов це, він повинен пройти наш невеликий тест на майстерність, і саме там іноді мене просять переглянути написаний код. Я не в змозі сказати «так» чи «ні». Я просто хочу знати, яким важливим повинен бути стиль кодування для мого огляду ...

Звідки ви знаєте, що у нього виникнуть проблеми з адаптацією? Просто тому, що вони використовують інший стиль кодування? Це досить нахабно. Я давно був підрядником, і незалежно від того, який стиль кодування використовується, ви адаптуєтесь. Це може зайняти деякий час, але звички формуються досить швидко.

Я сподіваюся, що під стилем кодування ви не маєте на увазі лише відступ та компонування коду. Це легко вирішити з використанням форматера коду та його інтеграції у вашу систему управління версіями.

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

Друга найважливіша річ у тому, яким стилем кодування хтось користується, - це те, що вони його використовують послідовно. Коли хтось, здається, використовує стиль кодування, але часто «грішить» проти нього, це ще один певний червоний прапор.

Програмуючи сотні різних проектів для майже сотні різних клієнтів, дозвольте підкреслити один момент.

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

Закінчуй з цим.

Я читав багато коду від безлічі різних програмістів. (Припустимо, середній розмір команди 5 і 100 різних команд. Це 500 колег.) Стиль не має значення.

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

[Є межа. Навмисне затуманення є підставою для припинення. Не маючи цього, стиль - це марна трата часу.]

Стиль кодування - це "остаточний кордон"

Якщо ви вирішили всі проблеми розробки програмного забезпечення; якщо ви можете створити код без помилок більш-менш миттєво; якщо ваш рівень якості настільки високий, ви більше не маєте черги на виправлення помилок; якщо ваша юзабіліті настільки казкова, у вас більше немає служби довідки; якщо ви в змозі безжально оптимізувати до місця, коли у вас немає ферми серверів, але запускайте підприємство з iPad ...

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

До цього часу існують численні питання, які є більшими та ціннішими за стиль.

Судячи з програмістів на основі стилю кодування, це 50% снобізм та 50% незахищеність.

Мені подобається, що мій код виглядає акуратним і чистим, і це звучить так, як і хлопець, який ОП ламав у посиланні. Наш код виглядає не однаково, але ми обидва використовуємо стиль, який допомагає нам зрозуміти код, коли ми повернемось до нього. У мене абсолютно не було проблем з розумінням його коду, і я сумніваюся, що ОП це зробив також. Стиль кодування "рада" - це не що інше, як легкий дешевий знімок, де ви можете передати свою величезну мудрість щодо того, чому фігурні брекети повинні бути в наступному рядку. Це зовсім не має значення. Що важко читати код:

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

У мене є проблеми уявити будь-який код, який не робив жодної з перерахованих вище речей, але все-таки важко було прочитати, особливо з таким інструментом, як Style Cop.

Це смішно мати формат коду бути фактором при прийнятті рішення , щоб найняти кого - то.

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

Не наймати хорошого розробника, тому що він не додає місця після коми - це безглуздо.

Я думаю, у вас офіційний стиль форматування в компанії.

Потім зробити надзвичайно просто переформатувати будь-яке джерело в офіційний стиль, і бажано зробити це автоматично щоразу, коли збережений вихідний файл.

Будь-який програміст, який коштує своєї солі, зробить любити це, оскільки це забезпечує більш високу якість, зводячи до мінімуму різниці для комісій.

Використовуйте StyleCop

Якщо ви використовуєте Visual Studio, ви завжди можете примусово застосовувати правила StyleCop до вашої компіляції, завдяки чому ваш код буде принаймні читабельним.

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

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

Дійсно було б чудово, якби будь-який із CVS підтримував форматування автоматичного коду під час реєстрації. Ви просто встановите пріоритети стилю, код буде відформатований перед збереженням. Це зробить специфічний для розробника стиль застарілим з точки зору форматування коду. Я можу побачити проблему, якщо деякі розробники використовують різні символи відступу. Для мене не так проблематично дивитися на інший код (і я можу його легко і швидко переформатувати), але з DIFF стає важче обробляти. Багато помилкових позитивних даних в інструменті DIFF.

Далі нижче наступні набагато важливіші деталі:

• Team Fit
• Можливості вирішення проблеми
• Зв'язок

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

Однак я, як правило, бачу зразок коду до остаточного інтерв'ю, і якщо стиль кодування далекий від того, що ми використовуємо, я зупинюсь на питаннях, які піддають їх здатності адаптуватися.

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

Якщо сучасний стиль відрізняється від того, яким ви користуєтеся, це не означає, що це погано. Для кандидата це може мати повний сенс.

Як сказали інші, проблема з адаптацією може бути єдиною проблемою.

Я б не сказав, що це категорична відсутність найму, але це сильний аргумент проти цієї людини.

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

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

(І так, я - кофеїнова залежність.)

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

Добрий стиль коду - питання особистого розвитку. Це показник, якого рівня цей програміст вже досяг.

Питання в тому, чи хоче ваша компанія "високих професіоналів" чи "високих потенціалів". Якщо вам потрібні "високі професіонали" і немає місця для навчання та еволюції - стиль коду є критерієм вибивання.

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