User Tools

Site Tools


principles:rule_of_explicitness

This is an old revision of the document!


Rule of Explicitness (RoE)

Variants and Alternative Names

  • Explicit Is Better Than Implicit (EIBTI)1)

Context

Principle Statement

Explicit is better than implicit.

Description

Rationale

Strategies

  • Avoid indirection (but keep LC in mind)
    • Avoid indirection though events/listeners/observers, etc. and use direct references instead.
    • Avoid indirecting middleware like messaging middleware in favor of direct communication. Explicit communication paths are easier to grasp and debug.
  • Avoid configurability (but keep GP in mind)
    • Avoid using configuration files for specifying behavior. Instead implement varying behavior explicitly.
    • Avoid highly configurable modules. Instead implement varying behavior explicitly.
  • Explicitly state which module to use
    • Avoid importing all classes of a given package/namespace and import the needed classes explicitly. In Java this means not to specify wildcard imports like import package.* and to avoid static imports. Similarly in Python this means not to use wildcard imports.
    • Avoid with statements in Delphi and other languages having constructs that let you invoke methods without explicitly stating the associated object.
  • Explicitly name parameters
    • In Python and other languages that allow this use named parameters.
    • Avoid long parameter lists and use objects with explicit attribute assignments instead. (see Option-Operand Separation)
    • Use parameter types that explicitly state what the input is. Rather use specific types for parameters like customers, articles, URLs, colors, money, etc. instead of using strings or integers for these values (see primitive obsession).
  • Avoid implicit type conversions.
    • In C# do not to specify implicit cast operations
    • In C++ use the explicit keyword on single-parameter constructors
    • In PHP use the === operator instead of == where the type matters

Caveats

See section contrary principles.

Origin

  • First without being explicitly stated RoE has been a central design principle of the programming language Python2). Python dates back to 1991.
  • Later this philosophy was stated as part of the “Zen of Python”3)
  • The rule—although often not stated as such—is also known outside the python community4).
  • Extend and origin beyond that remains unclear.
  • The name “rule of explicitness” is newly introduced here.

Evidence

  • Accepted: Explained by Martin Fowler in 5) and in virtually every Python book.

Relations to Other Principles

Generalizations

Specializations

Contrary Principles

  • More Is More Complex (MIMC): Stating something explicitly requires more code.
  • Generalization Principle (GP): RoE often results in specific solutions. Generality often requires stating something implicitly.
  • Low Coupling (LC): Direct communication typically has the disadvantage of a higher coupling. Indirection reduces coupling but creates implicit/indirect communication paths.

Complementary Principles

  • Keep It Simple Stupid (KISS): Explicit solutions are often also simpler.
  • Murphy's Law (ML):The typical reason for RoE is to avoid unnecessarily complicated solutions and possibilities for defects. Don't loose that goal out of sight.

Principle Collections

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU

Example

Description Status

Further Reading

1) , 3)
Tim Peters: The Zen of Python
2)
Guido van Rossum: Python's Design Philosophy
4) , 5)
Martin Fowler: To Be Explicit
principles/rule_of_explicitness.1363538172.txt.gz · Last modified: 2013-05-19 22:10 (external edit)