1 Comment

In addition to nulls, I'd suggest initializing string properties and fields with `string.Empty`. Same reasons as null.

I do this because I do a lot of parsing and if you think about it, there's no reason a non-db string value should be null. If it does happen to be null, then either a table field in our db came back null (which I dislike), or we simply forgot to set it, making for an easy fix.

Null has no context, but an empty string does. It has intent behind it, whereas null has ambiguity all the way up and down the stack!

Also, in C#, I have written extension methods like: `idStr.ToInt(fallback: -1)`. Inside the method is a ternary that checks for null or empty and returns the parsed id value and returns an int id of -1 if the parsing or null fails. The intent behind this is to discourage null strings and, if a string is null, have a reasonable, logical fallback value for business logic. And id the value is, say, a guid string, then the mehtod will throw an exception anyways.

Boom. All cases handled, and not a single deep, bug-prone if/else or try catch to be found.

Expand full comment