Skip to content

Simplify time assignment logic in AddModifyItem#15

Merged
jdubar merged 1 commit intomasterfrom
Simplify/notation-for-nulls
Nov 10, 2025
Merged

Simplify time assignment logic in AddModifyItem#15
jdubar merged 1 commit intomasterfrom
Simplify/notation-for-nulls

Conversation

@bechtd
Copy link
Copy Markdown
Collaborator

@bechtd bechtd commented Nov 10, 2025

Simplify time assignment logic in AddModifyItem

Refactor the switch statement in AddModifyItem to remove explicit casting of newTime to TimeSpan. Instead, directly assign the Value property of newTime to ItemToModify.Bedtime and ItemToModify.Waketime. This improves code clarity and reduces the risk of casting errors.

Why?

While casting does work, it's heavy-handed and possibly slower (ever so slightly).

newTime is already of type TimeSpan? (or Nullable<TimeSpan>). It already knows its "inner" type is TimeSpan; it doesn't need to be told this. The problem is that this is a nullable type, so how do you get from nullable to "not nullable" AFTER you know that it's not null (because of your earlier check).

The correct way is this notation .Value.

This says "OK, it's not null, so get the value then."

Also, though I think I prefer the newTime is null because it is expressed in "positive" logic, there is a "1st half" to the .Value notation for Nullables.

You can write this:
if (!newTime.HasValue)
instead of what you have:
if (newTime is null)

However, again, I prefer to read "positive", as opposed to "negative".

And new time is null reads A LOT BETTER THAN
not new time has value ... YUCK!

IF, however, the condition were the inverse, again because it is "positive" I would prefer this:
if (newTime.HasValue)
over the negative
if (newTime is not null)

They've made C# syntax so much easier to read around null checks, so yes, this second line isn't awful. It still reads just fine, but newTime.HasValue, especially when the next code would be newTime.Value, it fits.

Thinking in negatives is hard for most Humans.

Last note

A good reason why you probably haven't seen .HasValue and .Value much for nullables is because the null propagation ?. and null coalesce ?? operators:
newTime?.Seconds ?? 0;
Has helped to reduce so much null-check boilerplate code.

Refactor the `switch` statement in `AddModifyItem` to remove
explicit casting of `newTime` to `TimeSpan`. Instead, directly
assign the `Value` property of `newTime` to `ItemToModify.Bedtime`
and `ItemToModify.Waketime`. This improves code clarity and
reduces the risk of casting errors.
@codecov-commenter
Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jdubar jdubar added the refactor cleanup and improve code label Nov 10, 2025
Copy link
Copy Markdown
Owner

@jdubar jdubar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, simple change!! That's really cool - I wouldn't have known about Value otherwise.

@jdubar jdubar merged commit 51ea7e0 into master Nov 10, 2025
4 checks passed
@jdubar jdubar deleted the Simplify/notation-for-nulls branch November 10, 2025 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactor cleanup and improve code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants