3 ms·
Or join the ranks of your peers who have seen the light and use types. Documentation should always be secondary to an obvious, descriptive interface. We've evo
by xyzzy_plugh 5y ago
Or join the ranks of your peers who have seen the light and use types.
Documentation should always be secondary to an obvious, descriptive interface. We've evolved beyond register positions and phonebook-style paper documentation. Use the tools available to you.
- justinhj 5y agoThat would be the second paragraph in the article
- fouc 5y agothe article mentions strong types
- verandaguy 5y agoThe article addresses this somewhat using Python's type hints. If I give you his signature, can you intuitively tell me what unit is being taken in by the function? void addPadding(int height) { } Types are useful, and even as a Python programmer I gravitate towards type hints for all new code, but any application where a programmatic type maps to a real-world type with common conversions (like, say, pixels, em, en, millimetres, centimetres, or inches in the above example) tends to be a victim of the same issue, where the type system isn't expressive enough to clearly describe the real-world type being assumed by the function.
- matsemann 5y agoThat's because your not using the type system at all in your example. Change it to "addSomething(Length height)", and have constructors for Length.ofCm(2), Length.ofMeters(5) etc.
- verandaguy 5y agoSure, but this isn't a solution that's unique to statically-typed languages, and the syntax can get more awkward if you use a language without good OO support. I also haven't come across a thorough implementation of unit conversions to do stuff like this (not that it's not a pattern that works -- I personally like this); it might be common in domains where dealing with real units is central to the business, but in industries where that's done incidentally, convenience classes like this just aren't around (in my experience).