Please enable JavaScript.

Coggle requires JavaScript to display documents.

Р. Мартин "Чистый код. Создание, анализ и рефакторинг"…

- - - - Например имена hp, aix, sco ассоциируются с платформами и разновидностями Unix. Даже если hp кажется хорошим сокращением для хранения значения гипотенузы, оно может ввести в заблуждение читателя.
    - - public static void copyChars(char a1[], char a2[]) {
        for (int i = 0; i < a1.length; i++) {
        a2[i] = a1[i]; }
        }
        Такая функция будет читаться лучше, если присвоить аргументам имена source и destination.
    - - Существование в разных классах эквивалентных методов с похожими именами (fetch, retrieve, get или manager, controller, driver) создаст путаницу.
    - - Много классов с методами add, которые создают новое значение сложением или конкатенацией двух существующих значений (делают одно и то же).
        Новый класс с методом, который помещает свой единственный параметр в коллекцию хотя и похож по смыслу, имеет другую семантику, поэтому ему лучше присвоить имя insert или append.
    - - Имена accountAddress и customerAdress хорошо подходят для экземпляров класса Adress, но для классов такой выбор неудачен.
    - - Глава 3.
        
        Функции
        
        Блоки в командах if, else, while и т.д должны состоять из одной строки, в которой обычно содержится вызов функции.
        
        Этапы работы функции должны находиться на одном уровне абстракции. Чтобы определить это, попробуйте извлечь из ф-ии другую ф-ию, которая не являлась бы простой переформулировкой реализации.
        
        Функции пишутся прежде всего для разложения более крупной концепции (иначе говоря, имени ф-ии) на последовательность действий на следующем уровне абстракции.
        
        В идеальном случае количество аргументов функции равно нулю, далее следуют унарные и бинарные ф-ии. Функций с тремя аргументами следует по возможности избегать.
        
        Если функция должна получать более двух или трех аргументов, вероятно, что некоторые из них стоит упаковать в отдельном классе.
        
        Circle makeCircle(double x, double y, double radius);
        Circle makeCircle(Point center, double radius);
        
        В унарных функциях сама ф-ия и её аргумент должны образовывать естественную пару "глагол/существительное"
        
        writeField(name)
        assertExpectedEqualActual(expect, actual) решает проблему запоминания порядка аргументов.
        
        Не должно быть такого, что ф-ия обещает делать что-то одно, но делает что-то другое скрытое от пользователя. Например, вносит неожиданные изменения в переменные своего класса.
        
        Ф-ия checkPassword() не должна начинать сессию в случае совпадения. Она только проверяет пароль.
        
        Выходных аргументов следует избегать.
        Обращение к сигнатуре функции нарушает естественный ритм чтения кода.
        
        вместо этого: public void changeContactDetails(Person person)
        делать это: person.changeContactDetails()
        
        Функция должна что-то делать или отвечать на какой-то вопрос, но не одновременно. Либо изменяется состояние объекта, либо возвращается информация о нём.
        
        Вместо возвращения кодов ошибок, используйте исключения -- их включения в программу не требует перекомпиляции или повторного развертывания.
        
        Тела блоков try и catch рекомендуется выделять в отдельные функции, чтобы избежать смешения обработки ошибок и нормального выполнения. (обработка ошибок -- это одна операция, значит ф-ия не должна делать ничего другого)
        
        　
        
        Глава 4.
        
        Комментарии
        
        Объясните намерения в коде.
        Мы вынуждены использовать комментарии, потому что нам не всегда удается выразить свои мысли без них.
        
        Программисты редко нормально сопровождают комментарии. Программный же код изменяется и эволюционирует. Только код может сообщить, что он делает, комментарии устаревают
        
        Хорошие комментарии:
        
        Юридическое сопровождение, например, заявление об авторских правах.
        
        но только если вы убедились, что другого способа не существует
        
        Представление намерений (почему делаем так, зачем),
        
        Прояснение (загадочного аргумента или возвращаемого значения, если они являются частью стандартной библиотеки или нельзя изменить код, имена)
        
        Предупреждение о последствиях
        
        TODO, заметки "на будущее"
        
        Усиление, подчеркнуть важность
        
        Комментарии к общедоступным API
        
        Не комментируйте плохой код -- перепишите его.
        
        Плохие комментарии:
        
        Функции должны быть компактными. Желательно, чтобы длина не превышала 20 строк.