Цитаты из книги Clean Code: A Handbook of Agile Software Craftsmanship

Эта книга не сделает из вас хорошего программиста. Вы увидите множество примеров. А дальше дело только за вами. Помните старый анекдот о скрипаче, который заблудился по пути на концерт? Он остановил старика на углу и спросил, как попасть в Карнеги-холл. Старик посмотрел на скрипача, на зажатую у него под мышкой скрипку и сказал: "Старайся, сынок. Старайся!"

Каждый раз, когда вы пишите комментарий, — поморщитесь и ощутите свою неудачу.

Нет хуже причины для выбора имени с, чем та, что имена a и b уже заняты.

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

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

Закон Леблана: потом равносильно никогда.

Тогда, холодной зимой 1971 года в Чикаго, я узнал важный урок. Клиентская блокировка — полный отстой.

Сходное представление сходных концепций — информация. Непоследовательное представление — дезинформация.

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

...принцип проектирования классов в ООП, называемый принципом открытости/закрытости [PPP]: классы должны быть открыты для расширений, но закрыты для модификации. Наш переработанный класс Sql открыт для добавления новой функциональности посредством создания производных классов, но при внесении этого изменения все остальные классы остаются закрытыми.

Истину можно найти только в одном месте: в коде

Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо, и ничего другого она делать не должна.

Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее.

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

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

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

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

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

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