Действительно ли Стиль программирования важен? Как Важный? [закрытый]

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

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

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

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

Стиль Prgramming не ограничивает только для кодирования identation и комментария.
Код identation действительно очень важен для кода lizibility. Я никогда не видел код нес отступом, который было легко считать:).
то, Что также очень важно, является кодом, чтобы быть очевидным, комментарии должны использоваться только, когда реализация становится по различным таинственным причинам или где код не отражает ясно, ПОЧЕМУ автор записал ему тот путь. Я видел, что партии сверхпрокомментировали код, и я могу сказать Вам, видя, что комментарии почти о каждой строке похожи на читающие страницы оскорблений.
Так или иначе, я сомневаюсь, что Microsoft отклонила Вашего коллегу просто, потому что он не прокомментировал двойную реализацию связанного списка.

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

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

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

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

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

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

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

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

Не показ комментариев в тесте кодирования для интервью похож на нахождение экзамена и не показ любой работы!

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

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

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

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

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

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

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

if(someSituation) somethingElse++;

по сравнению с

if(someSituation)
    somethingElse++;

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

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

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

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

Иногда необходимо использовать библиотечную функцию, которую плохо называют. Можно сказать прочитайте руководство и идти дальше, или можно вставить сводный комментарий и сохранить следующего программиста (возможно, сами через 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);

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

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

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

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

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

Никакой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-R

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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