I worked with a small team on a C# project which used Code Contracts[0] in one of its products and another small team which used DbC[1] macros in C++ code bases.
Both enhanced the intrinsic quality of the code bases and served as a valuable augmentation to code documentation. They also served to enforce a "fail fast, fail loud" philosophy, which made defect identification quick to identify.
The down-side is that the checks were usually compiled out of production builds (due to performance concerns, real or imagined), so interface contracts were sometimes violated due to divergence between actual and expected use.
Typical resistance to using DbC was the same as other forms of code verification (such as unit testing).
Both enhanced the intrinsic quality of the code bases and served as a valuable augmentation to code documentation. They also served to enforce a "fail fast, fail loud" philosophy, which made defect identification quick to identify.
The down-side is that the checks were usually compiled out of production builds (due to performance concerns, real or imagined), so interface contracts were sometimes violated due to divergence between actual and expected use.
Typical resistance to using DbC was the same as other forms of code verification (such as unit testing).
0 - https://docs.microsoft.com/en-us/dotnet/framework/debug-trac...
1 - https://en.wikipedia.org/wiki/Design_by_contract