|
|
|
|
|
|
by MrDosu
4083 days ago
|
|
|
Personally I don't get contracts when they aren't used for static verification. It's much easier to use defensive coding techniques at runtime without having yet another framework in there that anyone who wants to read the code has to learn. Typing a few lines less is not really a benefit when it basically increases code complexity. |
|
|
A lot of languages (Java, C#, Go, etc.) have very inexpressive type systems, and that tends to make many dynamic language developers wary of them. Contracts has a very expressive type system though. It understands duck typing, adhoc union types, and a bunch of other stuff that makes it a great fit for a dynamic language.
Plus, we've disabled it in production, so we get coverage in test/development mode, but no performance penalty in prod. I look at it as an extended form of testing. Type contracts are very quick and easy to add, and they help tests catch additional errors. They're also useful in code reviews. Sometimes I'll have to search for 5 or 10 minutes to figure out what kind of thing is getting passed in, where the contract makes it perfectly clear.
The best part is that the contracts are optional. If some method takes wildly differing arguments and it's going to be a pain to give it a contract, then don't.
This is the best tool I've added to my Ruby arsenal in some time. I strongly recommend taking it for a spin.