Skip to content

BSL152 — Cached public methods

← All rules

Summary

Cached public methods

Identifiers

Field Value
Rule code BSL152
Compatible alias CachedPublic
Severity WARNING
Enabled by default Yes
Implemented Yes
Tags design, performance

Behavior

  • The public identifier BSL152 and alias CachedPublic are stable.
  • The rule reports the cases documented on this page.
  • Suppressions and project configuration are applied before publication.
  • The rule requires neither an external analyzer nor network access.

Configuration and suppression

BSL### is the primary stable identifier. The compatible alias is accepted in select, ignore, and compatible block suppression comments.

[tool.onec-hbk-bsl]
select = ["BSL152"]
ignore = ["CachedPublic"]

All three suppression families support both a current line and a range. When an opening comment follows code, it affects only that line. Use any one form:

  • noqa:
Value = "example";  // noqa: BSL152
  • bsl-disable:
Value = "example";  // bsl-disable: BSL152
  • compatible BSLLS form:
Value = "example";  // BSLLS:CachedPublic-off

When the same opening comment is on a line by itself, it starts a range. Close it with the matching marker from the same family:

// noqa: BSL152
// code without this diagnostic
// noqa-enable: BSL152

// bsl-disable: BSL152
// code without this diagnostic
// bsl-enable: BSL152

// BSLLS:CachedPublic-off
// code without this diagnostic
// BSLLS:CachedPublic-on

To disable the rule until the end of the file, omit the closing noqa-enable, bsl-enable, or BSLLS:…-on marker.

Opening and closing markers must belong to the same family.

Description

You should not create a programming interface in modules that reuse return values.

3.6. Another example of hiding library implementation details from a consumer. Suppose: in the first version of the library, consumers were provided with an export function of a common module with repeated use of return values; But in the next version of the library, this design decision was revised in favor of the “usual” general module, where this function was transferred (similarly, if in the opposite direction). In this example, in order to save the library user from additional efforts to replace calls of the "old" function with a new one, it is recommended to immediately place the export function in the "regular" module, in its section "program interface". Then this function, depending on the current design decision, can call the utility function from the module with repeated use of the returned values or from any other module, or directly contain the implementation. However, for the consumer, its location will no longer change in future versions of the library.

Examples

Sources