ITK has no written policy on when auto is appropriate, so every
mechanical-modernization PR re-litigates it in review.
The de-facto consensus that needs writing down
Surfaced in the review of #6014 (N-Dekker, dzenanz): ITK does not
follow "Almost Always Auto". auto is preferred where the type is
unambiguous from the initializer:
- factory calls —
Type::New(), Type::Filled(), MakeFilled()
- explicit casts —
static_cast<T>(...)
- iterators and range-
for
- structured bindings
and discouraged where it hides a numeric or pixel type that a reviewer
needs to see in order to judge the code.
Current documentation state
Documentation/AI/enforced-code-style.md — mentions auto once, in an
auto image = ImageType::New() example. No rule.Documentation/docs/contributing/ — no auto policy text at all.
Proposed deliverable
A short subsection in Documentation/docs/contributing/ (mirrored into
Documentation/AI/enforced-code-style.md) with allow/avoid examples, so
mechanical modernization PRs have a citable rule instead of a per-PR
argument.
Related: #6014, #6044.
ITK has no written policy on when
autois appropriate, so everymechanical-modernization PR re-litigates it in review.
The de-facto consensus that needs writing down
Surfaced in the review of #6014 (N-Dekker, dzenanz): ITK does not
follow "Almost Always Auto".
autois preferred where the type isunambiguous from the initializer:
Type::New(),Type::Filled(),MakeFilled()static_cast<T>(...)forand discouraged where it hides a numeric or pixel type that a reviewer
needs to see in order to judge the code.
Current documentation state
Documentation/AI/enforced-code-style.md— mentionsautoonce, in anauto image = ImageType::New()example. No rule.Documentation/docs/contributing/— noautopolicy text at all.Proposed deliverable
A short subsection in
Documentation/docs/contributing/(mirrored intoDocumentation/AI/enforced-code-style.md) with allow/avoid examples, somechanical modernization PRs have a citable rule instead of a per-PR
argument.
Related: #6014, #6044.