Правильный выбор флагов для расширения

Правильный выбор флагов для расширения
Правильный выбор флагов для расширения - sushioutlaw @ Unsplash

В моей библиотеке (DLL) есть расширения для List, подобные следующему.

<Runtime.CompilerServices.Extension>
Public Sub Store(Of TVal As IFullyOperable)(items As List(Of TVal), w As BinaryWriter, closeAfter As Boolean)
    Try
        w.Write7BitEncodedInt(items.Count)
        items.ForEach(Sub(i) i.Store(w))
    Catch ex As Exception
        Throw
    Finally
        If closeAfter Then w.Close()
    End Try
End Sub

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

Пока у меня есть флаг closeAfter в большинстве вызовов False, но я сомневаюсь, может лучше использовать leaveOpen как в конструкторе BinaryWriter из dotNet?

Использование leaveOpen приведет к избыточным инверсиям, но сделает код более похожим на часть dotNet, и может улучшить удобство использования, или нет?

Каковы соображения по поводу использования обоих вариантов?

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

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

Если в экосистеме .Net существует устоявшийся шаблон для параметра с семантикой leaveOpen, то это уже само по себе является хорошим аргументом в пользу того, чтобы следовать этому шаблону, поскольку это приведет к меньшей путанице для ваших пользователей. Если эффект для вашего кода также будет всего лишь простым not, то влияние на когнитивную нагрузку для ваших пользователей значительно перевесит когнитивную нагрузку для ваших сопровождающих.


LetsCodeIt, 18 декабря 2022 г., 13:53