Explicit is better than implicit.
Solutions often differ in the level of explicitness. A feature can be implemented explicitly or it can be a side-effect of the implementation of another feature or a more general functionality. The same applies to module communication. A module can invoke another module directly or there can be various forms of indirections like events or observers.
RoE states that explicit solutions are better than implicit ones. Indirection, side-effects, configuration files, implicit conversions, etc. should be avoided.
If something is realized explicitly, it is easier to understand. Implicit solutions require the developer to have a deeper understanding of the module as it is necessary to “read between the lines”. Implicit solutions also tend to be more complex. So explicit solutions are assumed to be less error-prone and easier to maintain.
import package.*and to avoid static imports. Similarly in Python this means not to use wildcard imports. In C++, do not import entire namespaces (e.g. do not use
using namespace std;).
withstatements in Delphi and other languages having constructs that let you invoke methods without explicitly stating the associated object.
explicitkeyword on single-parameter constructors
===operator instead of
==where the type matters
See section contrary principles.
Discuss this wiki article and the principle on the corresponding talk page.