Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Почему и что, а не как и где

Не документируйте несущественные детали, которые могут часто меняться.

// 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 должен знать.

    Сосредоточьтесь на этих эффектах и инвариантах, а не на самих деталях реализации.

    Повторим: детали реализации могут и будут меняться, поэтому их не нужно объяснять.

  • Не пишите о том, где что-то используется: это ещё одна информация, которая быстро устаревает.