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

Ответ 1

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

Всегда код, как будто парень, который заканчивает поддержка вашего кода будет насильственный психопат, который знает, где вы жить.- Мартин Голдинг _{(возможно)}

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Часть профессионалов, а не только некоторых script -kiddie, заботится о коде. Это о том, как кто-то еще прочитает этот код (может быть, даже вы!) Через шесть месяцев. Поэтому вы должны сделать это как можно проще для поддержания.

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

Ответ 16

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

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
}

Ответ 17

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

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

Ответ 18

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

Ответ 19

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

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

Ответ 20

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

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

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

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

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

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

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

Ответ 21

О стиле "стиль" (который я бы назвал "форматированием" ): это во многом вопрос личного вкуса, но работа в команде очень важна, определяя некоторые рекомендации, которые ВСЕГДА должны следовать, сгибая его личные предпочтения, если (в Eclipse мы экспортируем конфигурацию форматирования и с помощью нажатия клавиши мы получаем форматированный файл). Очень скоро все привыкнут к стандарту, и код чтения будет очень менее утомительным.

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

Ответ 22

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

Ответ 23

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

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

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

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

Ответ 24

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

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

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

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

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

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

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

Ответ 25

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

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

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

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

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

Ответ 26

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

Ответ 27

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

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

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

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

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

Ответ 28

Ну, там жизнь, а потом интервью.

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

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

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

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

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

Я подозреваю, что интервьюер искал много вещей, ВКЛЮЧАЯ хорошую практику кодирования (это на 1000 раз труднее "разучивать" плохую практику программирования, чем получить их с самого начала). Вероятно, интервьюер также искал что-то, что указывало бы на инициативу, хорошее допущение, возможно, даже на творчество или изобретательность.

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

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

-R

Ответ 29

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

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

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

Ответ 30

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

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

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

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