Упражнение: диалог о деталях
Ненужные детали иногда указывают на то, что действительно нуждается в документации.
// Copyright 2025 Google LLC
// SPDX-License-Identifier: Apache-2.0
/// Сортирует срез. Реализовано с помощью рекурсивной быстрой сортировки.
fn sort_quickly<T: Ord>(to_sort: &mut [T]) { ... }
-
Спросите класс: нужен ли этот комментарий для данной функции?
-
Сюжет: играя роль посредника между классом и автором, например менеджера продукта или руководителя, скажите классу, что автор этой функции возражает.
-
Спросите класс: почему автор комментария такого вида стал бы возражать?
Если класс спросит, почему автор возражает, пока не давайте подробностей.
-
Спросите класс: зачем вызывающему коду нужно знать используемый алгоритм сортировки?
-
Сюжет: «вернитесь» после встречи с исходным автором и объясните классу, что эта функция — код приложения, который вызывается для недоверенных данных, которые могут быть специально составлены так, чтобы вызвать квадратичное поведение при сортировке.
-
Спросите класс: теперь у нас больше подробностей; как нам прокомментировать эту функцию?
То, является ли что-то деталью реализации или нет, сильно зависит от того, каков публичный контракт (например, можно ли передавать недоверенные данные), и здесь нужна внимательная оценка.
Учтите, объясняет ли комментарий, что используется цикл
for(ненужная деталь), или он объясняет, что внутренние алгоритмы имеют известные уязвимости (документация привлекает внимание не к тому).