Важен ли стиль программирования? Как важно?

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

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

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

Однако, как правило, я ожидаю, что вы сделаете отступ в коде и добавите комментарии, где это необходимо. Фактически, наша сборочная машина откажет в таких мелочах, как включение в код табуляции вместо пробелов.

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

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

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

Обновлено: 2 часа для связанного списка ?! Я вижу, он имел в виду сейчас ... Уместить все это форматирование в оставшиеся один час пятьдесят минут было бы довольно сложно! (Я просто играю - полагаю, интервью было не только связным списком!)

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

Я полностью понимаю реакцию Microsoft - я бы ему тоже не перезвонил.

Стиль программирования очень важен. Комментарии тем более. Даже если вы работаете в одиночку, над своим собственным проектом, вы должны прокомментировать свой код, потому что через месяц вы не вспомните, что вы сделали и почему. А если вы работаете в команде, то нечеткий, неформатированный и не прокомментированный код может стать причиной катастрофы.

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

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

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

Вот почему я полагаюсь на инструмент для этого. Resharper позволяет мне переформатировать весь мой код, нажимая комбинацию клавиш Ctrl + F, E.

Код читают три объекта: компьютер, программист и, наконец, сопровождающий. Стиль и форматирование не имеют отношения к компьютеру, возможно, важны для программиста, но, безусловно, важны для сопровождающего, который должен попытаться понять функциональность программы. Отказ угодить другим разработчикам, сделав код читабельным, является неуважением. Создание организованного кода с осмысленными именами переменных и комментариями - это проявление вежливости ко всем, кто его читает.

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

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

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.-- Martin Golding _(maybe)

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

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

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

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

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

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

Стиль, в котором важен упор на читабельность. Чрезвычайно важно.

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

Я бы его уволил, но, к счастью, его никогда не наняли.

Я бы предпочел, чтобы он потратил 2 часа на написание чистого, почти работающего кода, чем чтобы он собрал что-то, что работает.

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

Забота о коде - это часть профессионала, а не просто сценариста. Речь идет о том, чтобы понять, что кто-то еще прочитает этот код (может быть, даже вы!) Через шесть месяцев. Следовательно, вы должны сделать его максимально простым в обслуживании.

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

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

Безусловно, важен стиль. Особенно, когда речь идет о таких вещах, как отступы и пробелы. Код должен быть легко читаемым человеком, поскольку он должен поддерживать этот код позже. Чем читабельнее код, тем проще его поддерживать и тем выше в конечном итоге станет этот код.

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

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

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

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

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

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

Нет

Стиль программирования абсолютно не важен. Важны ремонтопригодность и читаемость.

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

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

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

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

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

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

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

Все зависит от целевой аудитории исходного кода. Правильный ответ - «другие программисты» (сопровождающие и т. д.). Ваш коллега подумал, что это неважно, и я прекрасно понимаю, почему М.С. не нанял его. Я был бы удивлен, если бы какая-нибудь большая компания вообще его наняла!

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

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

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

Они снова измерили свою продуктивность, и в итоге ХУДШИЙ программист из первой группы набрал больше очков, чем ЛУЧШИЙ программист из второй группы.

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

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

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

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

Стиль программирования не ограничивается только идентификацией кода и комментированием. Идентификация кода действительно очень важна для гибкости кода. Я никогда не видел кода без отступов, который легко читался :).
Что также очень важно, так это то, что код не требует пояснений, комментарии должны использоваться только тогда, когда реализация становится по разным причинам зашифрованной или когда код не отражает ясно, ПОЧЕМУ автор написал это таким образом. Я видел много чрезмерно закомментированного кода и могу вам сказать, что видеть комментарии почти в каждой строке - все равно что читать страницы с оскорблениями. В любом случае, я сомневаюсь, что Microsoft отклонила вашего коллегу только потому, что он не прокомментировал реализацию двойного связного списка.

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

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

О «стиле» (который я бы лучше назвал «форматированием»): это в значительной степени вопрос личного вкуса, но работа в команде очень важна, определяя некоторые принципы, которым должен следовать КАЖДЫЙ, при необходимости изменяя свои личные предпочтения (в Eclipse мы экспортируем конфигурацию средства форматирования и нажатием клавиши мы форматируем файл). Очень скоро все привыкнут к стандарту, и чтение кода станет гораздо менее утомительным.

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

Вы можете возразить, что хорошо написанный код не нуждается в комментариях или, по крайней мере, в очень небольшом количестве комментариев. Но отсутствие отступов недопустимо. Компилятор заботится (в большинстве случаев), но люди, обслуживающие код, заботятся.

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

Документация обязательна даже по самому дурацкому коду. Было бы неплохо иметь шаблон для создания строк документации внутри вашего кода. Стандартизация и организационное соглашение внутри команды - лучший стиль.

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

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

Я был бы не против, если бы он не сразу комментировал. Но отступ важен. Когда вы пишете код, он редко выходит линейно из-за одного безумного набора текста.

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

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

Итак, первое, что я сделал, - исправил отступ. - самодовольно сказал он. «Не думаю, что это это исправит!». Я снова посмотрел на код. Теперь ошибку было легко обнаружить, поэтому я просто указал на нее и ушел.

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

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

Просто убедитесь, что он не доходит до уровня менеджера, заставляющего разработчика вносить изменения в обзор кода из чего-то вроде этого:

if ( someBool() ) doSomething();
else doNothing();

Что-то вроде этого просто потому, что они «чувствуют» его «лучший» стиль:

if ( someBool() )
{
    doSomething();
}
else
{
    doNothing();
}

Просто, пожалуйста, имейте причины лучше, чем личные предпочтения в отношении требований к стилю, и мы все будем счастливы.

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

Точно так же, если программист не уделяет время правильному написанию слов в блоках комментариев, именах функций и т. д., Это вызовет проблемы с другими разработчиками, пытающимися расшифровать код. Я всегда спрашиваю себя: «Я, если вы посмотрите на это через 1 неделю, вы поймете это? Если вы посмотрите на это в следующем году, вы все равно поймете это?» (или, по крайней мере, уметь читать документацию / комментарии, чтобы разбудить вашу память).

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

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

Хороший вопрос!

Я хотел бы знать, как любой порядочный программист может писать код без отступов, будь то в среде IDE, vi, блокноте, на доске или на заметке. Отступы в коде должны быть естественными. Я бы не перезвонил ему, если бы то, что он сдал, выглядело примерно так (я просто копирую реализацию из Википедии, акцент делается на отсутствие отступов):

struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev    := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}

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

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

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

Не показывать комментарии в тесте на кодирование для собеседования - все равно что сдавать экзамен и не показывать, что работает!

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

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

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

Вот почему необходимы стандарты кодирования. Команда должна придерживаться стандартов, даже если это не то, как они обычно кодируют. Он мог бы многому научиться для того, чтобы на самом деле поддерживать чужой беспорядок, как то, что есть у меня. 7000 строк C++ записываются в стиле C, разделенном на 7 методов (большинство методов - это более 600 строк), множество однострочных макросов, которые содержат переходы к меткам внутри методов. Также есть много однострочных операторов if и макросов, добавленных в конец этих и других вызовов методов, которые вы не увидите, потому что вам нужно прокрутить, чтобы увидеть их. Добавьте к этому ужасные имена переменных и непоследовательный стиль брекетинга, и вы получите непоправимый беспорядок. Положительным моментом является то, что он работает хорошо, и мы полагаемся на него годами.

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

Код написан для программистов (включая вас самих!), А не для компилятора. Если нам никогда не приходилось читать код, просто вбейте его шестигранной клавиатурой (как настоящий программист!) И покончите с этим! :-)

Но этого почти никогда не бывает. За время существования кода компилятор может потратить на его обработку всего несколько секунд. Но программисты могут потратить дни. И эти дни могут увеличиться до недель, если их трудно читать или понимать. Усилия должен должны быть затрачены на то, чтобы сделать код самодокументированным, но не полагайтесь на это. Всегда.

Отступ показывает поток управления. Связка строк без отступов может иметь поток управления, но это означает, что вам нужно прочитать каждую строку, чтобы ее обнаружить:

if (someSituation) somethingElse++;

против.

if (someSituation)
    somethingElse++;

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

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

Комментарии тоже важны. Если комментарии не соответствуют коду, то они оба неверны (я не помню, кто это первым сказал, но он мертв!).

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

Иногда вам нужно использовать библиотечную функцию с неудачным названием. Вы можете сказать RTFM и двигаться дальше, или вы можете добавить итоговый комментарий и сэкономить следующему программисту (возможно, самому через 6 месяцев) некоторые усилия.

// This allocates space for the message queue and initializes
// some OS overhead. All that remains after this is adjusting
// priority and content and then send the message.
prepareMessage(&myMessage);

Кроме того, если вы потратили 2 дня на поиск ошибки и внесли небольшое изменение в код, есть большая вероятность, что это изменение не было очевидным во время разработки. Иначе это было бы в первую очередь! Так что комментарий необходим, чтобы никто в будущем не вернул его к «очевидной» реализации.

memset(&myStatus, 0, sizeof(myStatus));

// The size member must be set before getting current values.
// This is used by library function GetCurrentStatus() to infer
// a version of the status structure.
myStatus.length = sizeof(myStatus);

GetCurrentStatus(&myStatus);

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

Стиль присущ всему, что мы делаем. Это не наложение. Это не надстройка. Это не привилегия. Он существует независимо от того, пользуемся мы им или нет. Вещи - программы, продукты, что у вас есть - не улучшаются стилем; они улучшаются благодаря ХОРОШЕМУ стилю (противоположность которому - просто плохой стиль).

Проблема с людьми, которые исходят из очень технически ориентированной точки зрения, заключается в том, что, если это не уравновешивается каким-либо эстетическим интересом или оценкой, предполагается, что «стиль» - это инструмент, не используемый программистами; «стиль» означает «оставьте это на усмотрение UI или маркетологов». Это просто неправда. Стремясь к лучшему в том, что вы делаете, вы должны улучшать все аспекты работы. Это означает не только исполнение, но и презентацию.

Люди - существа, ориентированные на зрение. Выбираем вещи по внешнему виду (Красивая девушка! Блестящая упаковка!).

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

Что ж, есть жизнь, а есть интервью.

Спросите своего друга - явится ли он на собеседование в рваных джинсах и грязной футболке?

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

Итак, если вы подаете заявление на работу программистом, зачем этот парень отправлял код «рваные джинсы и грязная футболка»?

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

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

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

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

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

-Р

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

Однако из того, что я видел, у большинства команд программистов (а иногда даже у целой компании) есть документ или что-то, объясняющее соглашения и стили кода, которых они придерживаются. Поэтому в первый день работы там довольно легко ввести их правила в вашу среду IDE и просто настроить автоматический формат вашего кода, чтобы вам не приходилось об этом беспокоиться. Более того, вы, вероятно, найдете кого-то, кто захочет «экспортировать» свой файл prefs, так что всего несколько щелчков мышью, пока весь код, который вы когда-либо напишете в этой компании, не будет отформатирован идеально.

При этом у вас не всегда будет доступ к этим специфическим для команды соглашениям (например, на собеседовании). Всегда полезно следовать некоторым понятным базовым соглашениям. В зависимости от вашего языка хорошей идеей было бы поискать в Google «Соглашения о коде ваш язык» и прочитать основы. Что важно в ситуации собеседования, так это то, что вы следуете некоторым основным рекомендациям и имеете стиль форматирования, которого вы придерживаетесь. Если вы сделаете скобку после утверждения «else» в той же строке один раз и напишете его в следующей строке в другой раз, вы, вероятно, говорите интервьюеру, что вам на самом деле все равно и / или вам не хватает переживать, что один путь стал для вас привычкой.

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

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

Стиль - это больше о том, кто мы есть, а не о том, что мы знаем.