Pull to refresh

Comments 61

UFO just landed and posted this here
я думаю что фундаментальные основы меняться и не должны :)
мне одному кажется что подобные заметки печатают все кому не лень?

основы меняться не должны, но нельзя же все время таблицу умножения проходить, нужно и дальше двигаться…
Все тезисы в том или ином виде уже где-то были написаны. Но они все еще актуальны, сколько бы об этом не писали.
Эх… Жизнь доказывает что сколько ни говори слово «сахар», во рту слаще не становится. :(
… Это МакКоннелл «Совершенный код»
Спасибо за ссылку. Наслышан об этой замечательной книге, к тому же всегда готов расширить свои познания.
Я тоже долгое время считал её замечательной :) Не сказать, что сильно изменил своё мнение, но честно говоря, как-то много очевидных вещей и вообще довольно скучный и нудный тон изложения. Зато понравился пример общения между программистами в главе про комментарии — вопрос только почему в других главах я подобного не видел.
это просто систематизированный справочник в помощь разработчику =) так что естественно там многое вам уже известно, ну и повторений много. но главное преимущество — все собрано воедино, четко описано, обосновано, и сложено в одной буке. аналогов у данной книги нет, а найти что-то новое там обязательно получится. так что все норм =)
Да, согласен. Лучше всего воспринимать её как справочник. Как и книгу Фаулера про рефакторинг
>> как-то много очевидных вещей

Однако на Хабре регулярно проскакивают посты про «во, что я придумал, как код писать надо», а там это уже есть ) Так что имхо польза неоценима — и как справочник в том числе.
непотопляемая тема качества кода =) чтото часто в послежнее время стала всплывать. так как Вы всегда готовы расширить свои познания, могу посоветовать следующую подборку книг(сам купил все в бумаге, ибо они стоят того)
1 — «Совершенный код» Стив Макконнелл
2 — «Рефакторинг. улучшение существующего кода» Мартин Фаулер
3 — «Рефакторинг с использованием шаблонов» Джошуа Кериевски
Тема действительно извечно актуальная ^__^ За рекомендацию книг спасибо, буду пополнять свою библиотеку.
UFO just landed and posted this here
То, что я в статье, называю «однозначностью», ближе к английскому слову «robustness». Да, форматирование кода скорее всего должно идти, как вы и предложили, в категории «читаемость». Здесь я упростил классификацию до трех фундаментальных категорий, на которых все основывается. А код может быть гибким. Например, код

if (a == 0) {
    a = 1;
}

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

Насчет комментариев углубляться в комментарии не буду. Мнение о необходимости в коде комментариев и их достаточности будет выражать тот, кому этот код достанется в наследство ^__^
Больше всего меня веселит фраза «Преждевременная оптимизация — корень всех бед». Сама фраза верная, хотя бы потому, что сказана Хоаром :) Но вот её применение… Эта фраза — спасательный круг для идиотов. Они ею прикрывают свой отрицательный IQ. Потому что понять какая оптимизация преждевременна, а какая просто необходима сразу же — могут не все. Посему, раздел «эффективность кода» следует отнести к advanced topics. Не надо давать её читать всем подряд — сэкономите нервы и себе и другим :)
Спасибо за мнение, тема оптимизации кода — преждевременной или нет — действительно из разряда продвинутых. Мой подход характерен тем, что все подается «как есть», без фильтрации. А уж воспринимается читателями в меру необходимости.
Это не критика вашей статьи, это ремарка. Всегда надо как-то образно описывать что-ли, где оптимизация преждевременна, а где нет.
«Хуже преждевременной оптимизации только преждевременная пессимизация» (с) Не помню кто сказал.
хорошая цитата, да и статья тоже! спасибо

весело бывает, когда считают «оптимизацией» что-то типа замены циклического вычисления факториала на рекурсивный — количество кода, конечно, меньше, а вот эффективность… По-моему, всегда лучше непонятный, но эффективный код (естественно, с обилием комментов), чем «самокомментирующий», но медленный.
Обычно как раз уход от рекурсии считается оптимизацией, а не наоборот. По поводу последней фразы не соглашусь — непонятный, но эффективный код лучше далеко не всегда, а только в тех случаях, когда эта часть алгоритма является узким местом, выявленным профайлингом. В остальных случаях на первом месте именно понятность и читаемость кода.
Это то самое что в любой области знаний называеться устойчивым ядром, спасибо
У меня такое ощущение, что я где-то это уже читал.
«даже для общеизвестных значений, таких как 3.14, 2.7, 9.8, 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) — весьма стоящая книжка, как следует осушать болота г**нокода )
Довольно редкая, кстати, тема. Чаще всего пишутся книги как правильно начинать и продолжать проект. А вот как правильно и эффективно разгребать оставшиеся в наследство авгиевы конюшни — нет.
И книга редкая. В Ozon, кажется, завезли в марте 1000 экземпляров (на русском). Если у кого нибудь есть электронка на русском, поделитесь, плиз — исключительно для ознакомления, конечно ;)
Есть на английском — не подойдёт?
Нет, спасибо, английскую нашел
Отличная книжка, кстати, подтверждаю. И что приятно, с юмором написана.
UFO just landed and posted this here
Идиотам уже ничто не поможет.
UFO just landed and posted this here
За свою жизнь ни разу не видел не то что совершенного кода, хотя бы сносного. Мой код пока даже хуже чем вижу, но непонятно к чему стремиться. Не раз от опытных программеров слышал что программирование занятие так себе и нормального софта не существует в природе, а за что не возьмись в конечном итоге оказываеться глючным глюкаловом.
Ну, так и есть. «Иногда приходится быстро бежать, чтобы просто оставаться на месте». Здесь так же.
Если вы пишете библиотеку функций, то сначала спроектируйте ее интерфейс и напишите код, который будет использовать функции из вашей пока еще не написанной библиотеки. Удобно пользоваться? Если нет, то это повод пересмотреть интерфейс, а поскольку сам функционал еще не написан, его не придется рефакторить.

Отличная фраза, скопировал к себе. Именно в этом была моя проблема!
Спасибо!
Тут старая проблема анализа и синтеза. Получается замкнутый круг: что бы анализировать (а именно определять интерфейс библиотеки), можно только имея уже нечто синтезированное (библиотека), а что бы синтезировать нужно анализировать… И так далее. Единственный выход — разработка маленькими быстрыми итерациями. А что раньше — интерфейс или реализация не так уж и важно ИМХО, главное возможность все переделать и прийти к компромиссному решению. Да здравствует Agile!
После написания нескольких десятков тысяч строк кода, обычно происходит качественный скачок в голове у среднестатистического программиста, и ВОЗМОЖНО он осознает, что нужны комментарии, что, хоть какой-нибудь стиль, лучше чем отсутствие оного, что идеальный код может не окупить затрат времени на вылизывание.
После этого, статья будет казаться очевидной. А до, все эти рекомедации будут казаться просто бухтением заросших стариков.
Позволю себе процитировать Джона Роббинса:
Однажды мой друг Франсуа Полин (François Poulin), который весь день занимается сопровождением кода, написанного другими, пришел со значком, на котором было написано: «Кодируй так, как будто тот, кто сопровождает твой код, — буйнопомешанный, который знает, где ты живешь».
Как то я эпиграф пропустил. Ну да ладно.
Совершенный код — это тот, который принёс много денег и больше не беспокоит в будущем.
Однозначность, эффективность и сопровождаемость — всего лишь инструменты. Не единственные и не всегда главные.
нестандартный подход, возможно и правда, поживем увидим
Какой там нестандартный. Возьмёшь большую программу: интерпрайз солюшн, один модуль на неё кучу денег стоит, а в исходники зайдёшь, так мама дорогая.
Людям свойственно идти по пути наименьшего сопротивления. Я не говорю, что это хорошо. Я говорю, что есть умные книги, а есть суровая правда жизни.
Не уверен на счет пункта про комментарии, так как если код непонятен без комментариев, то вряд ли это хороший код и в первую очередь стоит подумать над тем, как переписать его так, чтобы он не нуждался в комментариях.
Комментарий в хорошем коде должен появляться только в случаях, когда используется какое то вынужденное и весьма нетривиальное решение (например этот кусочек оказался самым узким местом в приложении и вы его оптимизировали), которое будет непонятно большинству разработчиков, которым может достаться ваш код (при этом стоит учитывать, что большинство как правило будет менее компетентным).
Также если дело дошло до комментирования, то стоит описывать не «что делает код», а «для чего/зачем он это делает».
Самодокументируемый код это хорошо, конечно, но чаще бывает быстрее прочитать комментарий, чем вникать в реализацию метода или структуру класса, для того, чтобы понять, что происходит.
Документирование и комментирование кода это разное или нет для вас? Например в java я за то, чтобы писать javadoc, а вот когда я хочу писать обычный комментарий, то уже задумываюсь о том, что не стоит ли изменить код…
Земена «постфиксный инкремент на префиксный» иногда экономит не наносекунды, если итератор является «тяжелым» объектом. Это не преждевременная оптимизация, а избежание излишней пессимизации.
См. Саттер, Александреску Стандарты программирования на C++ 101 правило и рекомендация.
В данном случае имеется в виду инкремент простого типа — числа или строки, в большинстве случаев использующийся в качестве отдельного выражения.
staic final public int AnswerToLifeTheUniverseAndEverything = 42;
Я правильно понял рекомендацию? :)
Sign up to leave a comment.

Articles