For the alarm we do not want to clear, we can add a big persistent clear count to make it impossible to reach. The ability to handle user's action of clearing alarm can be added later on.
Almost always you can write an ordinary function instead of a macro. The macros are not necessary. They attract bugs, make the code more complicated to debug, and can cause multiple false positives of static code analyzers since they cannot differentiate correct sly code from erroneous code.
I am simply suggesting to limit their usage as much as possible. You have 24 macros now in this file. What is the attachment to using them?
We all want to guard the code. Moreover, it's equally important that we write safe code that is clear to debug. Macros put into jeopardy the safety of our code because they make debugging much more difficult.
I don't understand Dara's response. It should be an else - making it an else if doesn't really have any effect except that now there is an implied else after the else if that you will not be able to get coverage for as it's unreachable. I think Quang is correct and it should be an else.
Had a conversation and also Peman mentioned that if a story is not ready we should not start it. Better to be cooperated and consulted with FW team for a clear definition of the required messages.
Yes, for now it's separated so I didn't break the ultrafiltration notification bar. A base and subcomponent structure makes sense. I'll take a look at doing that. Wasn't trying to change it without looping you in I was just trying to get the merge to compile and then ensure the unit tests passed.
