На что похож код хорошего программиста? [закрытый]
Примечание: Преобразование в строковое преобразование
Это происходит просто, если вы пытаетесь рассматривать массив как строку:
$arr = array('foo', 'bar');
echo $arr; // Notice: Array to string conversion
$str = 'Something, ' . $arr; // Notice: Array to string conversion
Массив не может быть просто echo 'd или конкатенируется с строкой, потому что результат не определен. PHP будет использовать строку «Array» вместо массива и вызвать уведомление, чтобы указать, что это, вероятно, не то, что было предназначено, и что вы должны проверять свой код здесь. Вероятно, вы захотите что-то вроде этого:
echo $arr[0]; // displays foo
$str = 'Something ' . join(', ', $arr); //displays Something, foo, bar
Или зациклируйте массив:
foreach($arr as $key => $value) {
echo "array $key = $value";
// displays first: array 0 = foo
// displays next: array 1 = bar
}
Если это уведомление появляется где-то, чего вы не ожидаете, это означает переменную, которую вы мысль - это строка, на самом деле это массив. Это означает, что у вас есть ошибка в коде, которая делает эту переменную массивом вместо ожидаемой строки.
31 ответ
Список ниже не является всесторонним, но это вещи, о которых я думал в рассмотрении Вашего вопроса.
-
Хороший код хорошо организован. Данные и операции в классах совмещаются. Между классами нет посторонних зависимостей. Это не похоже на "спагетти".
-
Хорошие комментарии к коду объясняют, почему вещи сделаны не, что сделано. Сам код объясняет, что сделано. Потребность в комментариях должна быть минимальной.
-
Хороший код использует значимые соглашения о присвоении имен для всех кроме самого переходного из объектов. название чего-то информативно о том, когда и как использовать объект.
-
Хороший код хорошо протестирован. Тесты служат исполняемой спецификацией кода и примерами его использования.
-
Хороший код не "умен". Это делает вещи простыми, очевидными способами.
-
Хороший код разрабатывается в маленьком, легком для чтения единиц вычисления. Эти единицы снова используются всюду по коду.
я еще не считал его, но книга, которую я планирую прочитать по этой теме, Чистый Код Robert C. Martin.
У меня есть хороший пример:
Чтение GWT (сеть Google tookit) Исходный код, Вы будете видеть, что каждый дурак понимает его (некоторые английские книги более трудно прочитать, чем этот код).
Иронически лучше программист меньше необходимое он становится, потому что произведенный код лучше удобный в сопровождении любым (как указано единогласно Eran Galperin).
Мой опыт говорит, что противоположное также верно. хуже программист более трудный поддержать его код, таким образом [еще 116] необходимый он становится, так как никакая другая душа не может понять произведенные загадки.
- лучший код имеет определенную элегантность, которую Вы распознаете, как только Вы видите его.
- Это выглядит обработанным с осторожностью и вниманием к деталям. Это, очевидно, производится с кем-то с навыком и имеет искусство об этом - Вы могли сказать, что это выглядит ваяемым и полируемым, а не грубым и готовым.
- Это последовательно и читает легко.
- Это разделяется на небольшие, очень связные функции, каждая из которых делают одну вещь и делать это хорошо.
- Это минимально связано, означая, что зависимости - немногие и строго управляемый, обычно...
- Функции и классы имеют зависимости от абстракции , а не реализации.
- Это работает
- , Это имеет модульные тесты, которые доказывают, что это работает
, Остальное - обледенение...
(Я использую "его" ниже, потому что это - человек, что я стремлюсь , чтобы быть, иногда с успехом).
я полагаю, что ядро философии хорошего программиста - то, что он всегда думает, что "Я кодирую для меня в будущем, когда я забуду все об этой задаче, почему я работал над ним, что было рисками и даже как этот код, как предполагалось, работал".
По сути, его код имеет к:
- Работа (не имеет значения, как быстрый код добирается до неправильного ответа. Нет никакого частичного кредита в реальном мире).
- Объясняют, как он знает, что этот код работает. Это - комбинация документации (javadoc, мой предпочтительный инструмент), обработка исключений и тестовый код. В очень реальном смысле я полагаю, что, строка для строки, тестовый код более ценен, чем функциональный код, если ни по какой другой причине, чем он объясняет "этот код работы, это - то, как это должно использоваться, и это - то, почему мне нужно заплатить".
- сохраняться. Мертвый код является кошмаром. Обслуживание унаследованного кода является тяжелой работой, но оно должно быть сделано (и помнить, это - "наследие" момент, что оно оставляет Ваш стол).
, С другой стороны, я полагаю, что хороший программист никогда не должен делать этих вещей:
- Зациклены на форматировании. Существует много IDE, редакторы и симпатичные принтеры, которые могут код формата к точно стандартному или персональному предпочтению, которое Вы чувствуете, являются соответствующими. Я использую Netbeans, я настроил параметры формата однажды и поразил alt-shift-F время от времени. Решите, как Вы хотите, чтобы код посмотрел, настроил Вашу среду и позволил инструменту сделать трудную работу.
- Зациклены на соглашениях о присвоении имен за счет человеческого общения. Если соглашение о присвоении имен ведет Вас в будущем именования Ваших классов "IElephantProviderSupportAbstractManagerSupport", а не "Служитель зоопарка", измените стандарт перед созданием его тяжелее для следующего человека.
- Забывают, что он работает командой с фактическими людьми.
- Забывают, что основной источник кодирования ошибок находится на его клавиатуре прямо сейчас. Если существует ошибка или ошибка, он должен обратиться к себе сначала.
- Забывают, что то, что распространяется вокруг, приходит. Какая-либо работа, которую он делает теперь для создания его кода более доступным для будущих читателей, почти наверняка принесет пользу ему непосредственно (потому что то, кто собирается быть первым человеком, попросило смотреть на его код? Он).
Код является отражением навыков и мышления программиста. Хорошие программисты всегда следят за будущим - как код будет функционировать, когда требования или обстоятельства не будут точно, что они сегодня. Как scalabale это будет? Насколько удобный это будет, когда я не буду тем, поддерживающим этот код? Насколько допускающий повторное использование код будет, так, чтобы кто-то еще делающий подобный материал мог снова использовать код и не записать его снова. Что, когда кто-то еще пытается понять код, который я записал.
, Когда у программиста есть то мышление, все другие падения материала на месте приятно.
Примечание: кодовая база работается на многими программистами со временем и обычно нет определенного обозначения кодовой базы программисту. Следовательно хороший код является отражением стандартов всей компании и качеством их трудовых ресурсов.
Хороший код - то, где Вы знаете то, что метод делает с имени. Плохой код - то, где необходимо разработать то, что код делает, для понимания имени.
Хороший код - то, где при чтении его можно понять то, что он выполняет не в намного большем количестве времени, чем он берет для чтения его. Плохой код - то, где Вы заканчиваете тем, что смотрели на него целую вечность пытающийся разработать wtf, он делает.
Хорошему коду назвали вещи таким способом как для создания тривиальных комментариев ненужными.
Хороший код имеет тенденцию быть коротким.
Хороший код может быть снова использован, чтобы сделать то, что он делает где-либо еще, так как он не полагается на материал, который действительно не связан с его целью.
Хороший код обычно является рядом простых инструментов, чтобы делать простые работы (соединенный хорошо организованными способами делать более сложные работы). Плохой код имеет тенденцию быть огромными многоцелевыми инструментами, которые легко повредить и трудный использовать.
Большой код мне - что-то, что просто схватить все же сложный. Вещи, которые заставляют Вас пойти, "ничего себе, конечно, почему я не думал о нем тот путь?". Действительно хороший код не трудно понять, он просто решает проблему под рукой простым способом (или рекурсивный путь, если это еще более просто).
Хороший код легко понять, легкий поддержать, и легкий добавить к. Идеально, это также максимально эффективно, не жертвуя другими индикаторами.
Jeff Atwood написал хорошую статью о том, как кодеры являются Машинистками первая ссылка: http://www.codinghorror.com/blog/archives/001188.html
будучи машинисткой всегда необходимо быть изящными в работе, имея strucutre, и надлежащая "грамматика" очень важна. Теперь преобразовывая это в "программирование" - ввод поймал бы тот же результат.
Структура
Комментарии
регионы
я - программное обеспечение engineere, что означает во время моего образования, я столкнулся со многими различными языками, но мое программирование всегда "чувствует" то же, как моя запись делает на fekberg.wordpress.com, у меня есть "специальный" путь к вводу.
Теперь программирующие различные приложения и на различных языках, таких как Java, C#, Ассемблер, C++, C я пришел к "стандарту" записи, что мне нравится.
я рассматриваю все как "поля" или регионы, и каждый регион имеет, он объясняет комментарий. Регион мог бы быть "классом Человек", и в этом регионе у меня есть несколько методов для свойств, которые я могу назвать "Методами доступа" или такой и каждое свойство, и регион имеет свой собственный комментарий объяснения.
Это очень важно, я всегда вижу свой код, который я делаю, как "являющийся частью API", когда создание структуры API и элегантности ОЧЕНЬ важно.
Думают об этом. Также прочитайте мою газету на Communication issues when adapting outsourcing, который объясняет в грубом, как плохой код может конфликтовать, Enterpret, как Вам нравится: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/
я второй рекомендация для боба дяди "чистый код". но можно хотеть смотреть на http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 , поскольку я думаю, что это имеет дело с конкретным вопросом немного лучше. хороший код должен прыгнуть от страницы и сказать Вам, что это/как, это работает.
Это, кажется, (должен быть), FAQ. Существует статья ACM о красивом коде недавно. Кажется, существует большой акцент на легкий для читения/понимания. Я был бы спецификатор это с "легким читать/понимать специалистами по проблемной области". Действительно хорошие программисты склонны использовать лучшие алгоритмы (вместо наивного, легкого понять O (n^2) алгоритмы) для любых данных проблем, за которыми могло быть трудно следовать, если Вы не знакомы с алгоритмом, даже если хороший программист дает ссылку на алгоритм.
Никто не прекрасен включая хороших программистов, но их код склоняются к , борются за:
- Правильность и эффективность с проверенными алгоритмами (вместо наивных и специальных взломов)
- Ясность (комментируют для намерения со ссылкой на нетривиальные алгоритмы)
- Полнота для покрытия основ (кодирующий соглашение, управление версиями, документацию, модульные тесты и т.д.)
- Сжатый (DRY)
- Устойчивость (эластичный к произвольному входу и разрушению запросов на изменение)
Я не видел 'Профессионала ASP.NET', но я был бы удивлен, лучше ли это, чем OK. См. этот вопрос для некоторых книг с действительно хорошим кодом. (Это варьируется, конечно, но принятый ответ, там твердо биться.)
Этому отвечают вполне прилично в книге Fowler, "Рефакторинге", Это - отсутствие всех "запахов", которые он описывает всюду по книге.
Я второй рекомендация "Чистого Кода Bob Martin".
"Красивый Код" высоко приветствовался несколько лет назад.
Любую из книг McConnell стоит прочитать.
, Возможно, "Прагматически настроенный Программист" был бы услужлив, также.
%
[Чисто субъективный ответ]
Для меня, хороший код является формой искусства, точно так же, как рисование. Я мог бы пойти далее и сказать, что это - на самом деле рисунок, который включает символы, цвета, "форму" или "структуру" кода, и со всем этим являющимся таким образом читаемым/производительным. Комбинация удобочитаемости, структура (т.е. столбцы, добавление отступа, даже имена переменной той же длины!), цвет (имена классов, имена переменной, комментарии, и т.д.) все делают то, что мне нравится рассматривать как "красивое" изображение, которое может сделать меня или очень гордым или очень detestful моего собственного кода.
(Как сказано прежде, очень субъективный ответ. Извините за мой английский язык.)
Скорее тогда повторите всех большие предложения else, я вместо этого предположу, что Вы читаете книжный Код, Завершенный Steve McConnell
По существу, это - книга, упакованная полный программирования лучших практик и для функциональности и для стиля.
Хороший код читаем. Вы не испытали бы никаких затруднений при понимании того, что код делает на первом, прочитанном кода, записанного хорошим профессиональным программистом.
Просто требуемый для добавления моих 2 центов... комментирует в коде - и код сам, обычно - должен сказать, что код делает, теперь как это делает это. Как только у Вас есть понятие 'клиентского' кода, который является кодом, который называет другой код (самым простым примером является код, который называет метод), Вы должны всегда больше всего волноваться по поводу создания Вашего кода, понятного с точки зрения "клиента". Когда Ваш код растет, Вы будете видеть, что это... мм, хорошо.
Много другого материала о хорошем коде об умственных прыжках, которые Вы сделаете (определенно, если Вы обратите внимание)... 99% из них имеют отношение к выполнению немного большего количества работы теперь для экономии Вас тонна работы позже и возможность многократного использования. И также с тем, чтобы делать правильно вещи: Я почти всегда хочу выполнить другой путь вместо того, чтобы использовать регулярные выражения, но каждый раз я вхожу в них, я вижу, почему все используют их на каждом языке, я работаю в (они являются глубокомысленными, но работа и вероятно не могла быть лучше).
Относительно того, посмотреть ли на книги, я сказал бы определенно не , по моему опыту. Взгляд на API и платформы и соглашения кода и код других людей и использование Ваши собственные инстинкты и попытка понять, почему материал является способом, которым это и каковы последствия вещей. Вещь, которые кодируют в книгах, почти никогда не делает запланировать незапланированное, которое является тем, о чем проверка ошибок - все. Это только окупается, когда кто-то посылает Вам электронное письмо и говорит, "Я получил ошибку 321" вместо "эй, приложение, повредился, эй".
Хороший код записан с будущим в памяти, и с точки зрения программиста и с перспективы пользователя.
Хороший код должен быть понятным.
Это должно быть хорошо прокомментировано.
Трудные части должны быть еще лучше прокомментированы.
- Легкий читать
- легкий записать
- легкий поддержать
все остальное - филигранная работа
Кратко помещенный, код хорошего программиста может быть считан и понят.
, По-моему, код хорошего программиста агностический языком ; правильно написанный код может быть считан и понят в короткий срок с минимальными взглядами, независимо от используемого языка программирования. Является ли код в Java, Python, C++ или Haskell, правильно написанный код понятен людьми, которые даже не программируют на том конкретном языке.
Некоторые характеристики кода, который легко считать, методы, которые хорошо названы, отсутствие "приемов" и замысловатой "оптимизации", классы хорошо разработаны, для именования некоторых. Как другие упомянули, , стиль кодирования последователен, сжат и простой .
, Например, на днях, я смотрел на код для TinyMCE для ответа на один из вопросов на Переполнении стека. Это записано в JavaScript, язык, который я едва использовал. Все же, из-за стиля кодирования и комментариев, которые включены, наряду со структурированием самого кода, это было довольно понятно, и я смог перейти через код через несколько минут.
Одна книга, которая была вполне разоблачение для меня в отношении чтения кода хорошего программиста, Красивый Код . Это имеет много статей, написанных авторами различных проектов программирования на различных языках программирования. Все же, когда я считал его, я мог понять то, что автор писал в своем коде несмотря на то, что я даже не запрограммировал на том конкретном языке.
, Возможно, то, что мы должны иметь в виду, - то, что программирование также о коммуникации, не только к компьютеру, но и людям , таким образом, код хорошего программиста почти похож на правильно написанную книгу, которая может связаться с читателем об идеях, которые это хочет передать.
Быть программирующим в течение почти 10 лет теперь самостоятельно и работавший с другими, я могу сказать беспристрастно, что нет никакого различия между хорошим программистом и средним кодом программистов
Все программисты на компетентном уровне:
- Комментарий Правильно
- Структура Эффективно
- Документ Чисто
я когда-то подслушал коллегу, говорят", я всегда был очень логичен и рациональный настроенный. Я думаю вот почему, что я люблю разрабатывать "
, Что, по-моему, ум среднего программиста. Тот, кто видит мир с точки зрения правил и логики и в конечном счете соблюдает те правила при разработке и записи программы.
опытный программист, понимает правила, но также и их контекст. Это в конечном счете приводит к ним придумывающий новые идеи и реализации, метку опытного программиста. Программирование является в конечном счете видом искусства.
Считайте книжный Завершенный Код. Это объясняет много идей о том, как структурировать код и причины того, чтобы сделать так. Чтение его должно закоротить Ваше время к aquiring опыт, необходимый для сообщения хороший от плохо.
Я программировал в течение 28 лет, и я нахожу это сложным вопросом для ответа. Мне хороший код является полным пакетом. Код чисто записан со значимыми именами переменной и именами методов. Это хорошо поместило комментарии, которые комментируют намерение кода, и только извергает код, который можно уже считать. Код делает то, что он, как предполагается, эффективным способом, не тратя впустую ресурсы. Это также должно быть записано глазом к пригодности для обслуживания.
нижняя строка, хотя то, что это означает разные вещи для различных людей. Что я мог бы маркировать как хороший код, кто-то еще мог бы ненавидеть. Хороший код будет иметь некоторые общие черты, которые я думаю, что определил выше.
лучшая вещь, которую можно сделать, представляют себя для кодирования. Посмотрите на код других людей. Проекты С открытым исходным кодом являются хорошим источником для этого. Вы найдете хороший код и плохой код. Чем больше Вы смотрите на него, тем лучше Вы распознаете то, что Вы решаете быть хорошим кодом и плохим кодом.
В конечном счете Вы будете своим собственным судьей. При нахождении стилей и методов, Вам нравится, принимают их, со временем Вы будете придумывать свой собственный стиль, и это будет изменяться со временем. Нет никакого человека на здесь, который может махнуть палочкой и сказать, что хорошо и что что-либо еще плохо.
Код является поэзией.
Начинают с этой точки логики, и можно получить многие желательные качества кода. Самое главное заметьте, что код читается намного больше, чем он записан, следовательно запишите код для читателя. Перепишите, переименуйте, отредактируйте и осуществите рефакторинг для читателя.
А следуют на заключении:
читатель будет Вами во время n с даты создания кода. Выплата записи кода для читателя является монотонно возрастающей функцией n. Читатель, смотрящий на Ваш код впервые, обозначается n == бесконечность.
, Другими словами, чем больше разрыв времени от того, когда Вы записали код в то, когда Вы пересматриваете код, тем больше Вы будете ценить свои усилия записать для читателя. Кроме того, любой, к которому Вы передаете свой код, получит большую выгоду от кода, записанного с читателем как передовое соображение.
А второе заключение:
Код, записанный без соображения для читателя, может быть излишне трудно понять или использовать. Когда соображение для читателя опускается ниже определенного порога, читатель получает меньше значения на код, чем значение, полученное путем перезаписи кода. Когда это происходит, предыдущий код выброшен и, трагически, много работы повторяется во время перезаписи.
заключение трети А:
Заключение два, как было известно, повторилось многократно в порочном круге плохо зарегистрированного кода, сопровождаемого принудительными перезаписями.
Лично, у меня будет к кавычке "Дзэн Python" Tim Peters. Это говорит Python программистам, на что должен быть похожим их код, но я нахожу, что это относится в основном ко всему коду.
Красивый лучше, чем ужасный.
Явный лучше, чем неявный.
Простой лучше, чем комплекс.
Комплекс лучше, чем сложный.
Плоский лучше, чем вложенный.
Редкий лучше, чем плотный.
количества Удобочитаемости.
Особые случаи не являются достаточно особенными для нарушения правил.
, Хотя практичность бьет чистоту.
Ошибки никогда не должны передавать тихо.
, Если явно не заставлено замолчать.
Перед лицом неоднозначности, откажитесь от искушения предположить.
должны быть один - и предпочтительно только один - очевидный способ сделать это.
, Хотя тот путь не может быть очевидным сначала, если Вы не голландцы.
Теперь лучше, чем никогда.
, Хотя никогда не часто лучше, чем [1 120] право теперь.
, Если реализацию трудно объяснить, это - плохая идея.
, Если реализацию легко объяснить, это может быть хорошая идея.
Пространства имен являются одной гудящей прекрасной идеей - давайте сделаем больше из тех!
Заключая Fowler в кавычки, summizing удобочитаемость:
Любой дурак может записать код, который может понять компьютер.
Хорошие программисты пишут код, который могут понять люди.
'сказанный ноль.
Первая вещь, которую Вы заметили бы, состоит в том, что их код следует за последовательным стиль кодирования . Они всегда пишут, что их структура блокирует то же, отступ неукоснительно, и прокомментируйте в соответствующих случаях.
вторые вещи, которые Вы заметили бы, состоят в том, что их код сегментируется на маленькие методы / функции, охватывающие не больше, чем пару дюжины строк самое большее. Они также используют сам описание имен методов, и обычно их код очень читаем.
за третьей вещью, которую Вы заметили бы, после того, как Вы бездельничали с кодом немного, который является логикой, легко следовать, легкий изменить - и поэтому легко удобный в сопровождении.
После этого, Вам будут нужны некоторые знания и опыт в методах разработки программного обеспечения для понимания определенного выбора, они взяли построение их архитектуры кода.
Относительно книг, я не видел много книг, где код можно было считать "мирового класса". В книгах они пробуют главным образом к примерам present simple, которые могли бы относиться к решению очень простых проблем, но не являются отражающими из более сложных ситуаций.