4 ms·

I'm fascinated by the idea of first-class support for preconditions/postconditions and class invariants. Has anyone worked on a large code base (whether in Eiff

by jaw 7y ago

I'm fascinated by the idea of first-class support for preconditions/postconditions and class invariants. Has anyone worked on a large code base (whether in Eiffel or not) that made extensive use of those constructs? Obviously it's common to put argument validity checks at the start of functions, and to check invariants at some critical points. But I'm curious how the existence of specially designated slots on every method/class for checking arbitrary invariants affects developer behavior and productivity.

AdieuToLogic 7y ago
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). 0 - https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... 1 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract
thesuperbigfrog 7y ago
Ada 2012 supports preconditions, postconditions, type predicates, and type invariants directly in the language: https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... It is wonderful for tracing errors and detecting problems, but can be a royal pain if you are refactoring substantial parts of the code / design.
troughway 7y ago
@jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera. I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™. Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold. We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems. Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand. Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy. .NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.
- pjmlp 7y ago
  Agree with you As for method_missing, what do you miss from IDynamicMetaObjectProvider and related classes?

by jaw 7y ago

AdieuToLogic 7y ago

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). 0 - https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... 1 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract

thesuperbigfrog 7y ago

Ada 2012 supports preconditions, postconditions, type predicates, and type invariants directly in the language: https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... It is wonderful for tracing errors and detecting problems, but can be a royal pain if you are refactoring substantial parts of the code / design.

troughway 7y ago

@jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera. I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™. Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold. We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems. Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand. Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy. .NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.

pjmlp 7y ago
Agree with you As for method_missing, what do you miss from IDynamicMetaObjectProvider and related classes?