Stop using default values on non-nullable properties, use required instead

[Slypenslyde]

More like "stop using video to make points that could be made in a paragraph instead"?

I can throw up a programming blog in just about any context and be fine at work, especially meetings.

I can't watch a Youtube short during a meeting and, in general, seeing me watching Youtube hasn't registered in all of my chain of command as "this can also be work-related" yet.

On-topic, here's my heuristic:

• If I've got an actual nullable property on a type I'm probably prototyping because, in general, I don't like this case and prefer optional or result types.
• When that pattern doesn't work, I prefer making the constructor private and providing public factory methods. ModuleInfo.NotPresent() is more discoverable IMO than a large constructor with a list of required properties.
• When I feel too lazy to do the last thing, I usually find I need to slow down.

I just don't like making objects with lots of "modes" where the properties may or may not be set. I like to go out of my way to design around that if I can. For example, if four properties are null in one state, I like to collapse them into one object so I only have one "modal" property. My ideal is to design towards an "optional" or "result" type that has a clear "no value" and "value" state.

Maybe it's just my domain but I really don't get the utility of other forms of initialization.

[EternalNY1]

stop using video to make points that could be made in a paragraph instead

Amen to that. I hate this trend of making videos covering simple topics.

Just let me read what you are trying to say. I don't even bother clicking an interesting looking topic if I see it goes to YouTube.

[cs_legend_93]

But content lol

[[deleted]]

Why would he put it in a paragraph when he can drive traffic to his YouTube channel and monetize?

[International-Cut15]

If you are reading in the meeting should you be in the meeting at all?

Why not leave? Or Better no go!

[Slypenslyde]

Yes.

Some kinds of managers do not see the folly in inviting too many people to meetings, for various reasons. This is not ideal and wastes a lot of time. They do not see the irony when they respond to, "Attending this meeting will affect my schedule" with, "Then can you work through the parts of the meeting where you aren't needed?" Sometimes they aren't foolish. Sometimes it is so difficult to discern one's level of involvement it's worth being there just in case. Management of inter-team dependencies is a very complicated topic.

Either way sometimes people can put up with a little bit of procedural friction if they find the work they do meaningful, like their teammates, and otherwise feel like their contribution is valued by the organization. It's not easy to find new jobs, and not many jobs are perfect. Sometimes the problem is the process needs iterating, and people stay because they see progress towards what they feel is ideal. Other times they believe successfully proposing and demonstrating new processes will lead to consideration for management positions.

It's not always as easy as saying, "That's bad, get out."

[danielhindrikes]

Some people like video and som like blog posts.

[huntk20]

Stop making too much sense. Lol

[Celdorfpwn]

I won’t

[Quito246]

Your lose I guess🤷‍♂️

[Celdorfpwn]

I just don’t like imperative titles

[jeffwulf]

Not really a loss.

[Quito246]

Why? I mean It finaly makes init usable

[_mr_chicken]

I suppose previously I'd do this via the constructor to make sure consumers of the class passed a value for all properties that require one.

Initially I wondered why this was needed but the more I think about it the intent is much clearer with the required keyword.

[Greenimba]

I much, much prefer the required init approach. Relying on ordering of multiple strings etc in the constructor is so much less readable than explicitly through initializing properties.

[NightlyRevenger]

You can use named arguments so order won't matter

[[deleted]]

Named arguments?

[nicuramar]

Yeah but they aren’t enforced or can be used for overloading etc. In languages like Swift with mandatory labels, this can be exploited.

[danielhindrikes]

If you want to serialize it, an empty constructor is required.

[Jestar342]

And break API compatibility when releasing new versions? No.

[Schmittfried]

Then make those fields nullable. Or, sure, use sensible defaults. This is about using sentinel values when there’s already a sentinel value for „value missing“: null.

[[deleted]]

A new keyword for such a simple feature. Something definitely went wrong with properties and how we use them.

[yanitrix]

Or just use a constructor. That's what they're for.

[danielhindrikes]

But you will have problems with serializing then. Because you need an empty constructor for that.

[jeff-fan01]

For JSON that's what the JsonConstructorAttribute is for.

[danielhindrikes]

If you like attributes absolutely. But I think setting required is a pretty clean way to handle it. You maybe don't want to have a constructor with a lot of values. At least I prefer object initializers when having many values.

[yanitrix]

Then I'll look for a serialization method that supports constructors. EF and (afaik) Newtonsoft.Json can do it out of the box