Почему и что, а не как и где
Не документируйте несущественные детали, которые могут часто меняться.
// Copyright 2025 Google LLC
// SPDX-License-Identifier: Apache-2.0
// плохо
/// Сохраняет запись `User` в базе данных Postgres.
///
/// Эта функция открывает новое соединение и начинает транзакцию. Она проверяет,
/// существует ли пользователь с данным ID, с помощью запроса `SELECT`. Если пользователь
/// не найден, выполняет `INSERT`.
///
/// # Errors
///
/// Возвращает ошибку, если любая операция с базой данных завершилась неудачно.
pub fn save_user(user: &User) -> Result<(), db::Error> {
// ...
}
// хорошо
/// Атомарно сохраняет запись пользователя.
///
/// # Errors
///
/// Возвращает ошибку `db::Error::DuplicateUsername`, если пользователь (с ключом из
/// поля `user.username`) уже существует.
pub fn save_user(user: &User) -> Result<(), db::Error> {
// ...
}
-
Мотивация: пользователи хотят знать контракт API (что гарантировано для этой функции), а не детали реализации.
-
Мотивация: комментарии, которые объясняют детали реализации, устаревают быстрее, чем комментарии, которые объясняют контракт.
Внутренняя информация, скорее всего, не важна для пользователя. Представьте, что в doc-комментарии к функции вы объясняете, что для решения задачи используете циклы
for: какой смысл в этой информации? -
Возможно, реализацию нужно объяснить, но, скорее всего, на самом деле нужно объяснить эффекты или инварианты, о которых пользователь API должен знать.
Сосредоточьтесь на этих эффектах и инвариантах, а не на самих деталях реализации.
Повторим: детали реализации могут и будут меняться, поэтому их не нужно объяснять.
-
Не пишите о том, где что-то используется: это ещё одна информация, которая быстро устаревает.