Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
спасибо, было интересно почитать
Попробуйте прочесть вот эту книгу — дополните ваш список еще 2мя десятками пунктов )
webmate.com.ru/ebooks/book410.html
webmate.com.ru/ebooks/book410.html
… Это МакКоннелл «Совершенный код»
Спасибо за ссылку. Наслышан об этой замечательной книге, к тому же всегда готов расширить свои познания.
Я тоже долгое время считал её замечательной :) Не сказать, что сильно изменил своё мнение, но честно говоря, как-то много очевидных вещей и вообще довольно скучный и нудный тон изложения. Зато понравился пример общения между программистами в главе про комментарии — вопрос только почему в других главах я подобного не видел.
это просто систематизированный справочник в помощь разработчику =) так что естественно там многое вам уже известно, ну и повторений много. но главное преимущество — все собрано воедино, четко описано, обосновано, и сложено в одной буке. аналогов у данной книги нет, а найти что-то новое там обязательно получится. так что все норм =)
>> как-то много очевидных вещей
Однако на Хабре регулярно проскакивают посты про «во, что я придумал, как код писать надо», а там это уже есть ) Так что имхо польза неоценима — и как справочник в том числе.
Однако на Хабре регулярно проскакивают посты про «во, что я придумал, как код писать надо», а там это уже есть ) Так что имхо польза неоценима — и как справочник в том числе.
непотопляемая тема качества кода =) чтото часто в послежнее время стала всплывать. так как Вы всегда готовы расширить свои познания, могу посоветовать следующую подборку книг(сам купил все в бумаге, ибо они стоят того)
1 — «Совершенный код» Стив Макконнелл
2 — «Рефакторинг. улучшение существующего кода» Мартин Фаулер
3 — «Рефакторинг с использованием шаблонов» Джошуа Кериевски
1 — «Совершенный код» Стив Макконнелл
2 — «Рефакторинг. улучшение существующего кода» Мартин Фаулер
3 — «Рефакторинг с использованием шаблонов» Джошуа Кериевски
То, что я в статье, называю «однозначностью», ближе к английскому слову «robustness». Да, форматирование кода скорее всего должно идти, как вы и предложили, в категории «читаемость». Здесь я упростил классификацию до трех фундаментальных категорий, на которых все основывается. А код может быть гибким. Например, код
предпочтительнее аналогичного кода без фигурных скобок, даже если в теле условия всего одно выражение. Код с фигурными скобками более «гибкий», поскольку позволяет добавить новые выражения в тело цикла, не затрагивая уже написанный код.
Насчет комментариев углубляться в комментарии не буду. Мнение о необходимости в коде комментариев и их достаточности будет выражать тот, кому этот код достанется в наследство ^__^
if (a == 0) {
a = 1;
}предпочтительнее аналогичного кода без фигурных скобок, даже если в теле условия всего одно выражение. Код с фигурными скобками более «гибкий», поскольку позволяет добавить новые выражения в тело цикла, не затрагивая уже написанный код.
Насчет комментариев углубляться в комментарии не буду. Мнение о необходимости в коде комментариев и их достаточности будет выражать тот, кому этот код достанется в наследство ^__^
Больше всего меня веселит фраза «Преждевременная оптимизация — корень всех бед». Сама фраза верная, хотя бы потому, что сказана Хоаром :) Но вот её применение… Эта фраза — спасательный круг для идиотов. Они ею прикрывают свой отрицательный IQ. Потому что понять какая оптимизация преждевременна, а какая просто необходима сразу же — могут не все. Посему, раздел «эффективность кода» следует отнести к advanced topics. Не надо давать её читать всем подряд — сэкономите нервы и себе и другим :)
хорошая цитата, да и статья тоже! спасибо
весело бывает, когда считают «оптимизацией» что-то типа замены циклического вычисления факториала на рекурсивный — количество кода, конечно, меньше, а вот эффективность… По-моему, всегда лучше непонятный, но эффективный код (естественно, с обилием комментов), чем «самокомментирующий», но медленный.
Обычно как раз уход от рекурсии считается оптимизацией, а не наоборот. По поводу последней фразы не соглашусь — непонятный, но эффективный код лучше далеко не всегда, а только в тех случаях, когда эта часть алгоритма является узким местом, выявленным профайлингом. В остальных случаях на первом месте именно понятность и читаемость кода.
Это то самое что в любой области знаний называеться устойчивым ядром, спасибо
У меня такое ощущение, что я где-то это уже читал.
Так и стараемся писать.
«даже для общеизвестных значений, таких как 3.14, 2.7, 9.8, 42»
Чем же число 42 общеизвестно? Число Каталана? Атомный номер Молибдена? В общем, даже с большой натяжкой, я не назвал бы 42 общеизвестым значением.
Чем же число 42 общеизвестно? Число Каталана? Атомный номер Молибдена? В общем, даже с большой натяжкой, я не назвал бы 42 общеизвестым значением.
это класика ru.wikipedia.org/wiki/Ответ_на_главный_вопрос_жизни,_вселенной_и_всего_такого
Слышал. В отличие от общеизвестных констант, хотел бы я посмотреть на программу в которой есть реальная польза от ответа на главный вопрос жизни, вселенной и всего такого :).
Воспринимайте наличие этой константы в списке общеизвестных просто как ссылку на отличную книгу
на самом деле стоит воспринимать это как иронию, потому что это такая же условная «константа» как и 3,14 9,8. в реальном приложении может понадобиться изменить точность и тогда придётся лазать по всем исходниках. в программировании вообще мало что может оставаться константами :( нужно быть готовым ко всему.
Кстати, Google калькулятор знает ответ на этот вопрос, достаточно в поиске ввести «answer to life, the universe, and everything».
Дежавю.
совершенного кода не бывает, но всегда можно что то улучшить в своем стиле. к сожалению, чаще всего нам в наследство достаются вещи грустные и унылые. очень хотелось бы почитать про «как понять бредовый чужой код»
Уже пишу на тему «Как жить с доставшимся в наследство бредовым кодом» ^__^ Благо опыт уже позволяет поделиться кое-какими приемами.
Вставлю свои 5 копеек )
М.Физерс «Эффективная работа с унаследованным кодом» (M.Feathers. Working Effectively with Legacy Code) — весьма стоящая книжка, как следует осушать болота г**нокода )
М.Физерс «Эффективная работа с унаследованным кодом» (M.Feathers. Working Effectively with Legacy Code) — весьма стоящая книжка, как следует осушать болота г**нокода )
Если вы пишете библиотеку функций, то сначала спроектируйте ее интерфейс и напишите код, который будет использовать функции из вашей пока еще не написанной библиотеки. Удобно пользоваться? Если нет, то это повод пересмотреть интерфейс, а поскольку сам функционал еще не написан, его не придется рефакторить.
Отличная фраза, скопировал к себе. Именно в этом была моя проблема!
Спасибо!
После написания нескольких десятков тысяч строк кода, обычно происходит качественный скачок в голове у среднестатистического программиста, и ВОЗМОЖНО он осознает, что нужны комментарии, что, хоть какой-нибудь стиль, лучше чем отсутствие оного, что идеальный код может не окупить затрат времени на вылизывание.
После этого, статья будет казаться очевидной. А до, все эти рекомедации будут казаться просто бухтением заросших стариков.
После этого, статья будет казаться очевидной. А до, все эти рекомедации будут казаться просто бухтением заросших стариков.
Позволю себе процитировать Джона Роббинса:
Однажды мой друг Франсуа Полин (François Poulin), который весь день занимается сопровождением кода, написанного другими, пришел со значком, на котором было написано: «Кодируй так, как будто тот, кто сопровождает твой код, — буйнопомешанный, который знает, где ты живешь».
Совершенный код — это тот, который принёс много денег и больше не беспокоит в будущем.
Однозначность, эффективность и сопровождаемость — всего лишь инструменты. Не единственные и не всегда главные.
Однозначность, эффективность и сопровождаемость — всего лишь инструменты. Не единственные и не всегда главные.
Не уверен на счет пункта про комментарии, так как если код непонятен без комментариев, то вряд ли это хороший код и в первую очередь стоит подумать над тем, как переписать его так, чтобы он не нуждался в комментариях.
Комментарий в хорошем коде должен появляться только в случаях, когда используется какое то вынужденное и весьма нетривиальное решение (например этот кусочек оказался самым узким местом в приложении и вы его оптимизировали), которое будет непонятно большинству разработчиков, которым может достаться ваш код (при этом стоит учитывать, что большинство как правило будет менее компетентным).
Также если дело дошло до комментирования, то стоит описывать не «что делает код», а «для чего/зачем он это делает».
Комментарий в хорошем коде должен появляться только в случаях, когда используется какое то вынужденное и весьма нетривиальное решение (например этот кусочек оказался самым узким местом в приложении и вы его оптимизировали), которое будет непонятно большинству разработчиков, которым может достаться ваш код (при этом стоит учитывать, что большинство как правило будет менее компетентным).
Также если дело дошло до комментирования, то стоит описывать не «что делает код», а «для чего/зачем он это делает».
Земена «постфиксный инкремент на префиксный» иногда экономит не наносекунды, если итератор является «тяжелым» объектом. Это не преждевременная оптимизация, а избежание излишней пессимизации.
См. Саттер, Александреску Стандарты программирования на C++ 101 правило и рекомендация.
См. Саттер, Александреску Стандарты программирования на C++ 101 правило и рекомендация.
staic final public int AnswerToLifeTheUniverseAndEverything = 42;
Я правильно понял рекомендацию? :)
Я правильно понял рекомендацию? :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Совершенный код