Nice but misleading graph.

If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case.

Can probably be implemented in a regular function with about 30 lines of code?

It's not hard to implement the logic when you have the rules. It's hard to define the rules.

> It's not hard to implement the logic when you have the rules. It's hard to define the rules.

Software development in a nutshell.

You're glossing over the fact that in order to have all of those complicated notification rules that users expect, you have to allow the user to set all of those complicated notification settings. You have to give them the ability to subscribe to threads, set notification preferences for a variety of items (channels, username mentions, keyword mentions, @here mentions, etc), set DND and exceptions, etc.

And maybe write test code for "all" possible combinations of settings.

Which is exactly the point the original poster was making. Software development on "simple" consumer apps is death by a thousand cuts.

It seems amusing that developers, of all people, wouldn't realize the power of exponentiation: https://en.wikipedia.org/wiki/Wheat_and_chessboard_problem :)

Lots of small things can add up to a lot of work though. A few extra percent per feature of complexity will ramp up quickly.

> If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for,

I think you might be under-counting the "No" cases.

I counted at least 30 (and then stopped, with plenty still to go) so I don't think you'll get it in 30 lines of code unless you have some very long lines with rather impenetrable logic.

How did you count 30? Are we looking at the same picture?

I counted 9.

- channel is muted and message not in a thread the user is subscribed to

- user in dnd-mode and there's no dnd-override

- this is a @channel mention but @channel mentions are suppressed

- message is for a thread user is subscribed to but channel notification perf is nothing

- notification preference for device is set to "never"

- @here mention but user is not active (not here)

- highlighted word in a thread message the user is not subscribed to

- channel notification preference is set to nothing

- I couldn't understand this condition (@mention in a comment on a file not owned by user?)

You can check these conditions sequentially and if any of them match, return false.

The last statement in the function would just `return true`.

The function needs a struct representing user preferences and a struct representing what's being currently parsed as inputs.

It's really not that complicated.

> How did you count 30?

Counting paths from the first node to the "NO" node rather than just counting total edges leading to the "NO" node.

Many of the conditions you mentioned are themselves determined based on various other conditions, and/or only triggered if certain paths (but not others) are followed.

> You can check these conditions sequentially and if any of them match, return false.

Not so.

For example, you could have the 'notification preference for device set to "never"', but there are paths through the flow diagram that evaluate to "YES" without ever going through the path that checks for the global device notification preferences.

Therefore if you are just sequentially checking each of the conditions you mentioned, then you'd be returning false (because that one statement matched) instead of true (because the flow should never go down that path).

> It's still a simple thing for one person to handle in a couple of days.

I don't disagree, I just think it's more effort than the 'regular function with about 30 lines of code' you first mentioned.