Всего за 0.01 руб. Купить полную версию
Функции:
Первый уровень структуризации.
Длина не избыточна.
Не содержит повторяющихся фрагментов кода.
Один уровень абстракции.
Функции компактны.
Функции еще компактнее.
Функции желательно не более 20 строк.
Все функции предельно очевидны.
Блоки в командах if, else, while и так далее должны состоять из 1 строки, в которой обычно вызов функции.
Функции не содержат вложенных структур.
Не более 12 отступов.
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна.
Если функция выполняет только те действия, которые находятся на одом уровне под объявленным именем функции, то эта функция выполняет одну операцию.
Функции пишутся прежде всего для разложения более крупной концепции (иначе говоря, имени функции) на последовательность действий в следующем уровне абстракции.
Чтобы определить, что функция выполняет более 1 операции, надо попробовать извлечь из нее другую функцию, которая бы не являлась простой переформулировкой реализации.
Функцию, выполняющую только одну операцию, невозможно осмысленно разделить на секции.
Все команды функции находятся на одном уровне абстракции.
За каждой функцией должны следовать функции следующего уровня абстракции.
Switch, длинные цепочки if-else скрывать в низкоуровневом классе и не дублировать в коде (использовать полиморфизм).
Принцип единой ответственности (single responsibility principle).
Принцип открытости-закрытости (open-closed principle).
Программа не содержит неограниченного количества других функций с аналогичной структурой (можно использовать абстрактную фабрику).
Имя точно описывает, что делает функция.
Длинное имя функции лучше короткого невразумительного.
Не бойтесь расходовать время на выбор имени функции.
В именах функций использовать те же словосочетания, глаголы и существительные, что и в модулях.
В идеальном случае количество аргументов функции равно нулю.
Использовать функции 1 аргумента:
для проверки некоторого условия, связанного с аргументом;
для обработки аргумента, его преобразования и возвращения;
для события (вход есть, выхода нет);
должно быть предельно ясно, что перед читателем событие;
остальных форм функций с 1 аргументом лучше избегать;
не использовать аргументы-флаги.
Бинарные функции оправданны, если оба аргумента упорядоченные компоненты одного значения.
Использовать все доступные способы для сведения функций к унарной форме.
Аргументы должны иметь естественную связь и естественный порядок.
Хорошо подумать перед созданием тернарной функции.
Упаковывать аргументы в объекты.
Если переменное количество равноправных аргументов упаковать в List.
Хорошее имя функции способно объяснить смысл функции, порядок и смысл ее аргументов.
В унарных функциях функция и аргумент должны образовывать естественную пару «глагол существительное».
Функция не делает чего-то скрытно от пользователя.
Нет побочных временных привязок функции.
Нет побочных эффектов.
Нет причин лишний раз обращаться к сигнатуре функции (нет повторных заходов).
Выходных аргументов следует избегать.
Функция может изменять состояние только владельца.
Функция либо что-то делает (команда), либо отвечает на какой-либо вопрос (запрос).
Функция либо изменяет состояние объекта, либо возвращает информацию об этом объекте.
Исключена неоднозначность имен функций.
Функции-команды не возвращают коды ошибок.
Вместо возвращения кодов ошибок используются исключения.
Тела блоков try/catch выделены в отдельные функции.
Функции выполняют 1 операцию.
Обработка ошибок одна операция.
Нет магнитов зависимостей классов или перечислений, импортируемых и используемых многими другими классами.
Нет дублирования алгоритмов.
Уменьшена вероятность ошибки.
Goto не используется.
Много return, break, continue допускается в компантных функциях.
В коде сначала излагаются мысли, а затем «причесываются».
Система рассматривается как история, которую нужно рассказать.
Комментарии неизбежное зло.
Только код может правдиво сообщить, что он делает.
Свести использование комментариев к минимуму.
Комментирование причина повысить качество кода.
Вместо юридических комментариев ссылки на них.
Информацию лучше передавать в имени функции.
Использовать комментарии для информации о намерении.
Комментарии в случае неудобочитаемых форм данных.
Комментарии для предупреждения о последствиях.
Комментарии TODO на будущее.
Комментарии для подчеркивания важности обстоятельства.
Не делать комментарии на скорую руку.
Комментирий не приводит к поиску расшифровки в других модулях.
Использовать аналог Javadoc.
Не комментировать бормотанием.
Не комментировать избыточно.
Комментарии точнее кода.
Комментарии точные и соответствуют коду.
Комментарий не вводит в заблуждение и не дезинформирует.
Бессмысленные или обязательные комментарии исключены.
Комментарий не повышает риск обмана и недоразумений.
Длинные журналы комментариев исключены.
Комментарии не загромождают и не усложняют код.
Комментарии-шумы исключены.
Комментарии не утверждают очевидное, не предоставляя новой информации.
Комментарии не бесполезны.
Комментарии не вызывают желания игнорировать их.
Комментарии не содержат эмоций.
Комментарии делают работу приятной и эффективной.
Комментарии не используются там, где можно использовать функцию или переменную.
Заголовки в комментариях применяются, когда приносят ощутимую пользу.
Закрывающие скобки не комментируются.
Ссылки на авторов в комментариях заменяются использованием системы контроля версий.
Нет закомментированного кода.
Нет HTML-комментариев.
Комментарии описывают код, к которому отнесены.
Комментарии не содержат дискуссий, исторических подробностей, не относящихся к делу.
Связь между комментарием и его кодом очевидна.
Цель комментария объяснить код, который не объясняет сам себя.
Комментарий не нуждается в объяснении.
Комментарии для API общего пользования не помещаются в коде, не предназначенном для общего потребления.
Комментарий упрощает понимание алгоритма пользователем.
Код должен быть хорошо отформатирован.
Форматирование облегчает передачу информации.
Маленькие файлы понятнее больших.
Типичная длина файла 200 строк, предел 500.
Исходный файл выглядит как статья.
Имя файла простое, но содержательное.
Имени файла достаточно, чтобы определить. этот модуль нужен или нет.
Начальные блоки файла описывают высокоуровневые концепции и алгоритмы.
Степень детализации увеличивается к концу файла.
В конце файла собираются все функции и подробности низшего уровня.
Код читается слева направо и сверху вниз.
Законченные мысли отделяются пустыми строками.
Строки кода с тесной связью должны быть сжаты по вертикали.
Тесно связанные концепции не находятся в разных файлах.
Следует избегать запущенных переменных.
Читателю не нужно прыгать туда-сюда по исходным файлам и классам.
Переменные объявляются максимально близко к месту использования.
Переменные перечисляются в начале каждой функции.
Управляющие переменные циклов объявляются внутри конструкции циrла.
Переменные экземпляров объявляются в начале класса.
Если одна функция вызывает другую, то они располагаются вблизи друг друга по вертикали.
Вызывающая функция располагается над вызываемой.
Концептуально родственные фрагменты кода располагаются близко друг к другу по вертикали.