чистый код pdf 2019
Чистый код. Мартин Р.
Плохой код может работать, но он будет мешать развитию проекта и компании-разработчика, требуя дополнительные ресурсы на поддержку и «укрощение». Каким же должен быть код? Эта книга полна реальных примеров, позволяющих взглянуть на код с различных направлений: сверху вниз, снизу вверх и даже изнутри. Вы узнаете много нового о коде. Более того, научитесь отличать хороший код от плохого, узнаете, как писать хороший код и как преобразовать плохой код в хороший. Книга состоит из трех частей. Сначала вы познакомитесь с принципами, паттернами и приемами написания чистого кода. Затем приступите к практическим сценариям с нарастающей сложностью — упражнениям по чистке кода или преобразованию проблемного кода в менее проблемный. И только после этого перейдете к самому важному — концентрированному выражению сути этой книги — набору эвристических правил и «запахов кода». Именно эта база знаний описывает путь мышления в процессе чтения, написания и чистки кода.
Содержание
Предисловие 14
Введение 20
Глава 1. Чистый код 23
Да будет код 24
Плохой код 25
Расплата за хаос 26
Грандиозная переработка 26
Отношение 27
Основной парадокс 28
Искусство чистого кода? 28
Что такое «чистый код»? 29
Мы — авторы 36
Правило бойскаута 37
Предыстория и принципы 37
Заключение 38
Литература 38
Глава 2. Содержательные имена (Тим Оттингер) 39
Имена должны передавать намерения программиста 40
Избегайте дезинформации 41
Используйте осмысленные различия 42
Используйте удобопроизносимые имена 44
Выбирайте имена, удобные для поиска 45
Избегайте схем кодирования имен 45
Венгерская запись 46
Префиксы членов классов 46
Интерфейсы и реализации 47
Избегайте мысленных преобразований 47
Имена классов 48
Имена методов 48
Избегайте остроумия 48
Выберите одно слово для каждой концепции 49
Воздержитесь от каламбуров 49
Используйте имена из пространства решения 50
Используйте имена из пространства задачи 50
Добавьте содержательный контекст 51
Не добавляйте избыточный контекст 53
Несколько слов напоследок 53
Глава 3. Функции 55
Компактность! 58
Блоки и отступы 59
Правило одной операции 59
Секции в функциях 60
Один уровень абстракции на функцию 61
Чтение кода сверху вниз: правило понижения 61
Команды switch 62
Используйте содержательные имена 64
Аргументы функций 64
Стандартные унарные формы 65
Аргументы-флаги 66
Бинарные функции 66
Тернарные функции 67
Объекты как аргументы 68
Списки аргументов 68
Глаголы и ключевые слова 68
Избавьтесь от побочных эффектов 69
Выходные аргументы 70
Разделение команд и запросов 70
Используйте исключения вместо возвращения кодов ошибок 71
Изолируйте блоки try/catch 72
Обработка ошибок как одна операция 72
Магнит зависимостей Error.java 73
Не повторяйтесь 73
Структурное программирование 74
Как научиться писать такие функции? 74
Завершение 75
Литература 78
Глава 4. Комментарии 79
Комментарии не компенсируют плохого кода 81
Объясните свои намерения в коде 81
Хорошие комментарии 81
Юридические комментарии 82
Информативные комментарии 82
Представление намерений 82
Прояснение 83
Предупреждения о последствиях 84
Комментарии TODO 85
Усиление 85
Комментарии Javadoc в общедоступных API 86
Плохие комментарии 86
Бормотание 86
Избыточные комментарии 87
Недостоверные комментарии 89
Обязательные комментарии 90
Журнальные комментарии 90
Шум 91
Опасный шум 93
Не используйте комментарии там, где можно использовать функцию или переменную 93
Позиционные маркеры 94
Комментарии за закрывающей фигурной скобкой 94
Ссылки на авторов 95
Закомментированный код 95
Комментарии HTML 96
Нелокальная информация 96
Слишком много информации 97
Неочевидные комментарии 97
Заголовки функций 97
Заголовки Javadoc во внутреннем коде 98
Пример 98
Литература 101
Глава 5. Форматирование 102
Цель форматирования 103
Вертикальное форматирование 103
Газетная метафора 104
Вертикальное разделение концепций 105
Вертикальное сжатие 106
Вертикальные расстояния 107
Вертикальное упорядочение 112
Горизонтальное форматирование 112
Горизонтальное разделение и сжатие 113
Горизонтальное выравнивание 114
Отступы 116
Вырожденные области видимости 117
Правила форматирования в группах 118
Правила форматирования от дядюшки Боба 118
Глава 6. Объекты и структуры данных 121
Абстракция данных 121
Антисимметрия данных/объектов 123
Закон Деметры 126
Крушение поезда 126
Гибриды 127
Скрытие структуры 127
Объекты передачи данных 128
Активные записи 129
Заключение 130
Литература 130
Глава 7. Обработка ошибок (Майк Физерс) 131
Используйте исключения вместо кодов ошибок 132
Начните с написания команды try-catch-finally 133
Используйте непроверяемые исключения 135
Передавайте контекст с исключениями 136
Определяйте классы исключений в контексте потребностей
вызывающей стороны 136
Определите нормальный путь выполнения 138
Не возвращайте null 139
Не передавайте null 140
Заключение 141
Литература 141
Глава 8. Границы (Джеймс Тренинг) 142
Использование стороннего кода 143
Исследование и анализ границ 145
Изучение log4j 145
Учебные тесты: выгоднее, чем бесплатно 147
Использование несуществующего кода 148
Чистые границы 149
Литература 149
Глава 9. Модульные тесты 150
Три закона TTD 151
О чистоте тестов 152
Тесты как средство обеспечения изменений 153
Чистые тесты 154
Предметно-ориентированный язык тестирования 157
Двойной стандарт 157
Одна проверка на тест 159
Одна концепция на тест 161
EI.R.S.T 162
Заключение 163
Литература 163
Глава 10. Классы (совместно с Джеффом Лангром) 164
Строение класса 164
Инкапсуляция 165
Классы должны быть компактными! 165
Принцип единой ответственности (SRP) 167
Связность 169
Поддержание связности приводит к уменьшению классов 170
Структурирование с учетом изменений 176
Изоляция изменений 179
Литература 180
Глава 11. Системы (Кевин Дин Уомплер) 181
Как бы вы строили город? 182
Отделение конструирования системы от ее использования 182
Отделение main 184
Фабрики 184
Внедрение зависимостей 185
Масштабирование 186
Поперечные области ответственности 189
Посредники 190
АОП-инфраструктуры на «чистом» Java 192
Аспекты AspectJ 195
Испытание системной архитектуры 196
Оптимизация принятия решений 197
Применяйте стандарты разумно, когда они приносят очевидную пользу 197
Системам необходимы предметно-ориентированные языки 198
Заключение 199
Литература 199
Глава 12. Формирование архитектуры 200
Четыре правила 200
Правило № 1: выполнение всех тестов 201
Правила № 2-4: переработка кода 201
Отсутствие дублирования 202
Выразительность 204
Минимум классов и методов 206
Заключение 206
Литература 206
Глава 13. Многопоточность (Бретт Л. Шухерт) 207
Глава 14. Последовательное очищение 225
Реализация Args 226
Как я это сделал? 233
Args: черновик 233
На этом я остановился 245
О постепенном усовершенствовании 246
Аргументы String 248
Заключение 286
Глава 15. Внутреннее строение JUnit 287
Инфраструктура J Unit 288
Заключение 302
Глава 16. Переработка SerialDate 303
Прежде всего — заставить работать 304
. Потом очистить код 306
Заключение 320
Литература 321
Глава 17. Запахи и эвристические правила 322
Приложение А. Многопоточность II 357
Пример приложения «клиент/сервер» 357
Знайте свои библиотеки 367
Зависимости между методами могут нарушить работу многопоточного кода 370
Повышение производительности 375
Взаимная блокировка 377
Тестирование многопоточного кода 381
Средства тестирования многопоточного кода 384
Полные примеры кода 385
Приложение Б. org.jfree.date.SerialDate 390
Приложение В. Перекрестные ссылки 455
Эпилог 458
Алфавитный указатель 459
Чистый код: создание, анализ и рефакторинг
Скачать книгу
О книге «Чистый код: создание, анализ и рефакторинг»
В программировании много тонкостей, и, если не учесть некоторые моменты, код может не работать. Однако часто встречаются случаи, что код рабочий, но не слишком «чистый», плохо написанный. В книге «Чистый код: создание, анализ и рефакторинг» Мартин Роберт учит работать с кодом и рассказывает, какие изменения внести, если код нужно доработать. Можно, конечно, и не вносить никаких изменений, но тогда на поддержку кода потребуется гораздо больше ресурсов.
Это учебник для тех программистов, которые хотят стать настоящими профессионалами, а не представителями среднего и низшего уровней. Код здесь рассматривается с разных сторон, изучается так, как только возможно. Автор рассказывает о важных принципах, даёт советы, как написать чистый код. Он приводит большое количество примеров. Затем он предлагает разные сценарии с нарастающей сложностью. Есть упражнения, в которых нужно очистить код или отредактировать так, чтобы при работе возникало меньше проблем. В завершении книги автор говорит обобщённо обо всех правилах и о мышлении, которое должно быть у программиста во время написания и чистки кода.
Книга научит отличать хорошие и плохие коды, изменять их в лучшую сторону. Читатели смогут узнать много нового. Большое количество понятных примеров делают книгу доступной даже для новичков. Всё это легко применимо на практике, как при работе с языком Java, так и при работе с другими языками программирования.
На нашем сайте вы можете скачать книгу «Чистый код: создание, анализ и рефакторинг» Мартин Роберт бесплатно и без регистрации в формате pdf, читать книгу онлайн или купить книгу в интернет-магазине.
Чистый код. Создание, анализ и рефакторинг (fb2)
[url=https://coollib.net/b/486351]
[b]Чистый код. Создание, анализ и рефакторинг (fb2)[/b]
[img]https://coollib.net/i/51/486351/cover.jpg[/img][/url]
QR-код книги
Аннотация
Даже плохой программный код может работать. Однако если код не является «чистым», это всегда будет мешать развитию проекта и компании-разработчика, отнимая значительные ресурсы на его поддержку и «укрощение».
Эта книга посвящена хорошему программированию. Она полна реальных примеров кода. Мы будем рассматривать код с различных направлений: сверху вниз, снизу вверх и даже изнутри. Прочитав книгу, вы узнаете много нового о коде. Более того, вы научитесь отличать хороший код от плохого. Вы узнаете, как писать хороший код и как преобразовать плохой код в хороший.
Книга состоит из трех частей. В первой части излагаются принципы, паттерны и приемы написания чистого кода; приводится большой объем примеров кода. Вторая часть состоит из практических сценариев нарастающей сложности. Каждый сценарий представляет собой упражнение по чистке кода или преобразованию проблемного кода в код с меньшим количеством проблем. Третья часть книги – концентрированное выражение ее сути. Она состоит из одной главы с перечнем эвристических правил и «запахов кода», собранных во время анализа. Эта часть представляет собой базу знаний, описывающую наш путь мышления в процессе чтения, написания и чистки кода.
Примечание верстальщика: книга содержит большой объем исходников (code), так что не рекомендуется применять скрипты «Генеральная уборка», «Обработка кавычек» и т. д.
«Чистый код» Роберт Мартин. Конспект. Как писать понятный и красивый код?
Я решил написать конспект книги, которая всем известна, а сам автор называет ее «Школой учителей Чистого кода». Пристальный взгляд Мартина как бы говорит:
«Я тебя насквозь вижу. Ты опять не следуешь принципам чистого кода?»
Глава 1. Чистый код
Что же такое этот самый чистый код по версии Мартина в нескольких словах? Это код без дублирования, с минимальным количеством сущностей, удобный для чтения, простой. В качестве девиза можно было бы выбрать: «Ясность превыше всего!».
Глава 2. Содержательные имена
Имена должны передавать намерения программиста
Имя переменной, функции или класса должно сообщить, почему эта переменная существует, что она делает и как используется. Если имя требует дополнительных комментариев, значит, оно не передает намерений программиста. Лучше написать, что именно измеряется и в каких именно единицах.
Пример хорошего названия переменной: daysSinceCreation;
Цель: убрать неочевидность.
Избегайте дезинформации
Не используйте слова со скрытыми значениями, отличными от предполагаемого. Остерегайтесь малозаметных различий в именах. Например, XYZControllerForEfficientHandlingOfStrings и XYZControllerForEfficientStorageOfStrings.
По-настоящему устрашающие примеры дезинформирующих имен встречаются при использовании строчной «L» и прописной «O» в именах переменных, особенно в комбинациях. Естественно, проблемы возникают из-за того, что эти буквы почти не отличаются от констант «1» и «0» соответственно.
Используйте осмысленные различия
Если имена различаются, то они должны обозначать разные понятия.
«Числовые ряды» вида (a1, a2,… aN) являются противоположностью сознательного присваивания имен. Они не несут информации и не дают представления о намерениях автора.
Неинформативные слова избыточны. Слово variable никогда не должно встречаться в именах переменных. Слово table никогда не должно встречаться в именах таблиц. Чем имя NameString лучше Name? Разве имя может быть, скажем, вещественным числом?
Используйте удобопроизносимые имена: generationTimestamp намного лучше genymdhms.
Выбирайте имена, удобные для поиска
Однобуквенные имена могут использоваться только для локальных переменных в коротких методах.
Избегайте схем кодирования имен
Как правило, кодированные имена плохо произносятся и в них легко сделать опечатку.
Интерфейсы и реализации
Я (автор книги) предпочитаю оставлять имена интерфейсов без префиксов. Префикс I, столь распространенный в старом коде, в лучшем случае отвлекает, а в худшем — передает лишнюю информацию. Я не собираюсь сообщать своим пользователям, что они имеют дело с интерфейсом.
Имена классов
Имена классов и объектов должны представлять собой существительные и их комбинации: Customer, WikiPage, Account и AddressParser. Старайтесь не использовать в именах классов такие слова, как Manager, Processor, Data или Info. Имя класса не должно быть глаголом.
Имена методов
Имена методов представляют собой глаголы или глагольные словосочетания: postPayment, deletePage, save и т. д. Методы чтения/записи и предикаты образуются из значения и префикса get, set и is согласно стандарту javabean.
Воздержитесь от каламбуров
Задача автора — сделать свой код как можно более понятным. Код должен восприниматься с первого взгляда, не требуя тщательного изучения. Ориентируйтесь на модель популярной литературы, в которой сам автор должен доступно выразить свои мысли.
Добавьте содержательный контекст
Контекст можно добавить при помощи префиксов: addrFirstName, addrLastName, addrState и т. д. По крайней мере читатель кода поймет, что переменные являются частью более крупной структуры. Конечно, правильнее было бы создать класс с именем Address, чтобы даже компилятор знал, что переменные являются частью чего-то большего.
Переменные с неясным контекстом:
Функция длинновата, а переменные используются на всем ее протяжении. Чтобы разделить функцию на меньшие смысловые фрагменты, следует создать класс GuessStatisticsMessage и сделать три переменные полями этого класса. Тем самым мы предоставим очевидный контекст для трех переменных — теперь абсолютно очевидно, что эти переменные являются частью GuessStatisticsMessage.
Переменные с контекстом:
Не добавляйте избыточный контекст
Короткие имена обычно лучше длинных, если только их смысл понятен читателю кода. Не включайте в имя больше контекста, чем необходимо.
Глава 3. Функции
Компактность!
Первое правило: функции должны быть компактными.
Второе правило: функции должны быть еще компактнее.
Мой практический опыт научил меня (ценой многих проб и ошибок), что функции должны быть очень маленькими. Желательно, чтобы длина функции не превышала 20 строк.
Правило одной операции
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна. Если функция выполняет только те действия, которые находятся на одном уровне под объявленным именем функции, то эта функция выполняет одну операцию.
Секции в функциях
Функцию, выполняющую только одну операцию, невозможно осмысленно разделить на секции.
Один уровень абстракции на функцию
Чтобы убедиться в том, что функция выполняет «только одну операцию», необходимо проверить, что все команды функции находятся на одном уровне абстракции.
Смешение уровней абстракции внутри функции всегда создает путаницу.
Чтение кода сверху вниз: правило понижения
Код должен читаться как рассказ — сверху вниз.
За каждой функцией должны следовать функции следующего уровня абстракции. Это позволяет читать код, последовательно спускаясь по уровням абстракции в ходе чтения списка функций. Я называю такой подход «правилом понижения».
Команды switch
Написать компактную команду switch довольно сложно. Даже команда switch всего с двумя условиями занимает больше места, чем в моем представлении должен занимать один блок или функция. Также трудно создать команду switch, которая делает что-то одно — по своей природе команды switch всегда выполняют N операций. К сожалению, обойтись без команд switch удается не всегда, но по крайней мере мы можем позаботиться о том, чтобы эти команды были скрыты в низкоуровневом классе и не дублировались в коде. И конечно, в этом нам может помочь полиморфизм.
В примере представлена всего одна операция, зависящая от типа работника.
Эта функция имеет ряд недостатков. Во-первых, она велика, а при добавлении новых типов работников она будет разрастаться. Во-вторых, она совершенно очевидно выполняет более одной операции. В-третьих, она нарушает принцип единой ответственности (Single responsibility principle), так как у нее существует несколько возможных причин изменения.
В-четвертых, она нарушает принцип открытости/закрытости (The Open Closed Principle), потому что код функции должен изменяться при каждом добавлении новых типов.
Но, пожалуй, самый серьезный недостаток заключается в том, что программа может содержать неограниченное количество других функций с аналогичной структурой, например:
isPayday(Employee e, Date date)
deliverPay(Employee e, Money pay)
Все эти функции будут иметь все ту же ущербную структуру. Решение проблемы заключается в том, чтобы похоронить команду switch в фундаменте абстрактной фабрики и никому ее не показывать. Фабрика использует команду switch для создания соответствующих экземпляров потомков Employee, а вызовы функций calculatePay, isPayDay, deliverPay и т. д. проходят полиморфную передачу через интерфейс Employee.
Мое общее правило в отношении команд switch гласит, что эти команды допустимы, если они встречаются в программе однократно, используются для создания полиморфных объектов и скрываются за отношениями наследования, чтобы оставаться невидимыми для остальных частей системы. Конечно, правил без исключений не бывает и в некоторых ситуациях приходится нарушать одно или несколько условий этого правила.
Используйте содержательные имена
Половина усилий по реализации этого принципа сводится к выбору хороших имен для компактных функций, выполняющих одну операцию. Чем меньше и специализированнее функция, тем проще выбрать для нее содержательное имя.
Не бойтесь использовать длинные имена Длинное содержательное имя лучше короткого невразумительного. Выберите схему, которая позволяет легко прочитать слова в имени функции, а затем составьте из этих слов имя, которое описывает назначение функции.
Аргументы функций
В идеальном случае количество аргументов функции равно нулю. Далее следуют функции с одним аргументом (унарные) и с двумя аргументами (бинарные). Функций с тремя аргументами (тернарных) следует по возможности избегать.
Выходные аргументы запутывают ситуацию еще быстрее, чем входные. Как правило, никто не ожидает, что функция будет возвращать информацию в аргументах. Если уж обойтись без аргументов никак не удается, постарайтесь хотя бы ограничиться одним входным аргументом.
Преобразования, в которых вместо возвращаемого значения используется выходной аргумент, сбивают читателя с толку. Если функция преобразует свой входной аргумент, то результат
должен передаваться в возвращаемом значении.
Аргументы-флаги
Аргументы-флаги уродливы. Передача логического значения функции — воистину ужасная привычка. Она немедленно усложняет сигнатуру метода, громко провозглашая, что функция выполняет более одной операции. При истинном значении флага выполняется одна операция, а при ложном — другая.
Бинарные функции
Функцию с двумя аргументами понять сложнее, чем унарную функцию. Конечно, в некоторых ситуациях форма с двумя аргументами оказывается уместной. Например, вызов Point p = new Point(0,0); абсолютно разумен. Однако два аргумента в нашем случае являются упорядоченными компонентами одного значения.
Объекты как аргументы
Если функция должна получать более двух или трех аргументов, весьма вероятно, что некоторые из этих аргументов стоит упаковать в отдельном классе. Рассмотрим следующие два объявления:
Если переменные передаются совместно как единое целое (как переменные x и y в этом примере), то, скорее всего, вместе они образуют концепцию, заслуживающую собственного имени.
Глаголы и ключевые слова
Выбор хорошего имени для функции способен в значительной мере объяснить смысл функции, а также порядок и смысл ее аргументов. В унарных функциях сама функция и ее аргумент должны образовывать естественную пару «глагол/существительное». Например, вызов вида write(name) смотрится весьма информативно.
Читатель понимает, что чем бы ни было «имя» (name), оно куда-то «записывается» (write). Еще лучше запись writeField(name), которая сообщает, что «имя» записывается в «поле» какой-то структуры.
Последняя запись является примером использования ключевых слов в имени функции. В этой форме имена аргументов кодируются в имени функции. Например, assertEquals можно записать в виде assertExpectedEqualsActual(expected, actual). Это в значительной мере решает проблему запоминания порядка аргументов.
Разделение команд и запросов
Функция должна что-то делать или отвечать на какой-то вопрос, но не одновременно. Либо функция изменяет состояние объекта, либо возвращает информацию об этом объекте. Совмещение двух операций часто создает путаницу.
Изолируйте блоки try/catch
Блоки try/catch выглядят весьма уродливо. Они запутывают структуру кода и смешивают обработку ошибок с нормальной обработкой. По этой причине тела блоков try и catch рекомендуется выделять в отдельные функции.
Обработка ошибок как одна операция
Функции должны выполнять одну операцию. Обработка ошибок — это одна операция. Значит, функция, обрабатывающая ошибки, ничего другого делать не должна. Отсюда следует, что если в функции присутствует ключевое слово try, то оно должно быть первым словом в функции, а после блоков catch/finally ничего другого быть не должно.
Чистый код: создание, анализ и рефакторинг (pdf+epub)
Посоветуйте книгу друзьям! Друзьям – скидка 10%, вам – рубли
Эта и ещё 2 книги за 299 ₽
Отзывы 16
Несмотря на то, что некоторые вещи, расмотренные в книге, кажутся очевидными, зачастую даже опытные программисты упускают их из виду. Поэтому книга подойдет как новичкам в программировании, так и «гуру». Для новичков это прекрасный шанс привить себе навыки грамотного написания и документирования кода.
Большая часть примеров написана на Java, однако советы, собранные здесь, прекрасно подходят и для других языков программирования.
Для чтения книги желательно (но не обязательно) хотя бы поверхностное знакомство с паттернами проектирования.
Несмотря на то, что некоторые вещи, расмотренные в книге, кажутся очевидными, зачастую даже опытные программисты упускают их из виду. Поэтому книга подойдет как новичкам в программировании, так и «гуру». Для новичков это прекрасный шанс привить себе навыки грамотного написания и документирования кода.
Большая часть примеров написана на Java, однако советы, собранные здесь, прекрасно подходят и для других языков программирования.
Для чтения книги желательно (но не обязательно) хотя бы поверхностное знакомство с паттернами проектирования.
Читал книжку в оригинале. Конечно те, кто пишет на Java получать максимум из книги, но и тем, кто работает с другими языками, будут очень полезны первые 30% книги – как правильно называть переменные, как организовать класс, сколько аргументов лучше передавать в функцию и т.д. Все эти вещи проходят всколзь при подготовке программистов в ВУЗах, а ведь именно из таких мелочей и складываются хорошие системы. Вообще, стоит прочитать точно всем программистам.
Читал книжку в оригинале. Конечно те, кто пишет на Java получать максимум из книги, но и тем, кто работает с другими языками, будут очень полезны первые 30% книги – как правильно называть переменные, как организовать класс, сколько аргументов лучше передавать в функцию и т.д. Все эти вещи проходят всколзь при подготовке программистов в ВУЗах, а ведь именно из таких мелочей и складываются хорошие системы. Вообще, стоит прочитать точно всем программистам.
Книга обязательна к прочтению всем программистам. Я читал ее в начале своего пути, как программиста. Идеи книги неоднократно меня выручали. Однако, автор преподносит эти идеи в немного категоричном тоне. К рекомендациям стоит относиться с осторожностью. Если строго следовать каждому совету – получится преждевременная оптимизация программы со всеми вытекающими негативными последствиями.
Подходит для любого языка программирования – советы универсальные.
Книга обязательна к прочтению всем программистам. Я читал ее в начале своего пути, как программиста. Идеи книги неоднократно меня выручали. Однако, автор преподносит эти идеи в немного категоричном тоне. К рекомендациям стоит относиться с осторожностью. Если строго следовать каждому совету – получится преждевременная оптимизация программы со всеми вытекающими негативными последствиями.
Подходит для любого языка программирования – советы универсальные.