> Unlike with an bare int, a "Month" type has places to actually document all that Good chance it won't actually be documented there though, or that the docume

> Unlike with an bare int, a "Month" type has places to actually document all that Good chance it won't actually be documented there though, or that the documentation will lie. Similarly, that documentation can easily live on a date-style object, where it's more likely to be accurate. > So your counter argument, which is entirely the same for an int anyway, is utterly absurd. No, I've eliminated several possibilities with a plain int that you've conveniently left unquoted. I do still have some ambiguity, but less, and gained clarity in several things you've - again - conveniently left unquoted. It's not perfect, but it's an improvement. > I don't really know what your point even is here. Your ide or code base is bad, therefore everyone should share your pain? Every codebase has some bad code, and my point is - even with good IDE assistence - a typedef still requires digging. And if my own personal experience is anything to go by, most codebases have a lot of bad code. If you've been blessed with only perfect codebases handed down to you from the gods themselves, pristine and pure, maybe Month is less opaque for you than it is to me. You have my sympathy for the shock and horror you'll experience should you ever touch code writtten by mere mortals ;) > It's the same end result of a wrapper type being vastly superior to a bare int. I challenge you to share a single real life bug that you've managed to catch or prevent with a strong month type. Go on, I'll wait. Or show me some code from a real codebase where a stronger month type actually improves readability more than, say, a variable named month_index or month_no. Show me a concrete example of this vast superiority improving the readability of a function in a real codebase. Or where it's lack has made things confusing, and the mere addition of "Month" would provide clarity. > I could never do the same for an "int" variable. You can absolutely attach comments and documentation to variables, methods, and properties. https://learn.microsoft.com/en-us/dotnet/api/system.datetime.month?view=net-7.0#property-value https://learn.microsoft.com/en-us/dotnet/api/system.datetime... Oh gee, is that an `int` month property that states it's range? Yes. Yes it is. And I don't have to drill further into the documentation to look at the type of the property, and can just look at the property? Bonus points! > It really sounds like you're just wanting to obsessively nitpick the specific example of "Month" than anything about what the guideline is even saying. I'm providing context to point out the limits of the guideline and where it goes too far, using it's own example. Hardly obsessive nitpicking. > If you're just too lazy to make a Month then sure knock yourself out. But at least be honest that you're just being lazy in the now with a hope it doesn't bite you later, don't pretend you're making an actually better or more readable decision. We all take the lazy out from time to time. Don't get me wrong, I'm incredibly lazy. Otherwise known as cost efficient. I have better things to do than to create or untangle a mess of opaque types that do little more than obfuscate the code for some hypothetical type safety that - based on personal experience - won't actually add any safety in practice, won't catch any bugs, won't provide a meaningful improvement to documentation or code readability, and will just slow me down and take time away from working on something that might actually be important (perhaps some practical type safety.) I would hope my coworkers also have better things to do with their time as well. The possibilities and backlog are infinite, but our time is not.