Автор: Чжоу Мэнкан

Не делайте свой код непонятным для других, потому что вы можете быть одним из тех, кто прочитал неразборчивый код через неделю. Всегда контролируйте себя, помня, что другому разработчику может потребоваться много времени для обработки ошибок, если в ваших фрагментах кода есть ошибки.

В повседневной практике программирования старайтесь улучшить свои семантические выражения. Это принесет вам большую пользу. В частности, как мы можем добиться хороших семантических выражений?

Примеры кода в этой статье - это только мой тестовый код и не относятся ни к каким реальным проектам.

Именование ваших функций и параметров

Дело 1

Случай 2

Только с этим именем функции и именем параметра кто сможет выяснить фактическое значение этого параметра?

Случай 3

Случай 4

Предположим, что в наш бизнес-код включены следующие классы.

Однако при запросе к базе данных мы обнаруживаем следующее:

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

Дополнительные примечания

Добавление комментариев к вашему коду

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

Эти вопросы могут прийти вам в голову. Однако знаете ли вы, как написать комментарий к объекту-члену массива?

Вы умеете писать комментарии к вызовам магических методов класса?

Массив объектов

Использование @method

Использование @deprecated

Дополнительные соображения

Комментарии и описания совпадают правильно. Имена методов обновляются, а бизнес-комментарии и комментарии к методам не обновляются. Информационная запись @author также копируется в процессе копирования чужого кода, и автор исходного кода в конечном итоге берет на себя вину за ошибки кода.

Дополнительную информацию о комментариях см. На веб-странице http://manual.phpdoc.org/HTMLframesConverter/default/

Функции и методы

Дело 1

Во-первых, я хочу прояснить одну вещь: код с плохой читаемостью не обязательно означает, что программное обеспечение плохое. Часто можно увидеть много плохих фрагментов кода PHP и MySQL.

Ниже приведен фрагмент кода проекта с открытым исходным кодом. Функция на самом деле отличная. Однако в этом методе слишком много содержания. На рисунке я перечислил некоторые недостатки кода.

Случай 2

Вы еще помните эту цифру?

Решение для оптимизации 1 Решение для оптимизации 2

$startId и $lastId - повторяющиеся параметры.

Случай 4

Минимизируйте ссылки на параметры

function bad($input1, $input2, &$input3)
{
    //...logic
    $input3 = "xxx";
    return true;
}

Дело 5

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

Дело 6

В этом примере addUser написан таким образом, что он больше похож на удаленный интерфейс API, чем на функцию (метод). Во фрагменте кода, показанном справа, нам нужно делать выводы на основе is_array каждый раз, когда мы его используем. Это недружелюбное смысловое выражение. Исключения могут возникать в продвинутых языках, таких как PHP и Java. Нам нужно хорошо использовать исключения.

Хорошие семантические выражения упрощают реализацию эффективных итераций в совместной команде и устранение неполадок неизвестного кода в режиме онлайн. Это конец этого блога. Вы узнали что-то новое?

Первоисточник