05-13-2025, 11:55 PM
Honestly, I like this old code better than the _IIF statement:
'IF n.ac THEN ' If note enharmonic
' IF Vtog%(shrp_flt) THEN ' If in flat mode
' NoteName$ = n.bf
' ELSE ' If in sharp mode
' NoteName$ = n.bs
' END IF
'ELSE ' If note NOT enharmonic
' NoteName$ = n.nt
'END IF
Things are spread out on multiple lines and each segment is commented to help understand what it's supposed to be doing. I'd personally find the above much easier to maintain and work with after a 6 month break, where I might find myself having to go back and rework the code for some error or new enhancement, than I would the _IFF alternative.
NoteName$ = _IIF(n.ac, _IIF(Vtog%(shrp_flt), n.bf, n.bs), n.nt)
There's a lot less code there for you to write and work with, but also a lot less explanation of what's going on with that code. It's just user defined types which you might not remember what every element stands for in the future, and arrays and indexes, and... a huge question mark which says, "WTF WAS THIS DOING?!!"
It may save you a few bytes disk space and compact the code down a byte or two, but you have to consider if it's going to be worth the hit to readability and maintenance with the future of the code. Over the years, I've thrown together a LOT of quick and sloppy code, and been proud of it at the time, only to have to almost rewrite the whole thing from scratch a couple years later just because I couldn't figure out my own damn flow and logic with stuff. LOL!
My opinion with _IFF is that it's convenient, but it's a tool that I'd personally tend to use for fairly obvious stuff which isn't hard to decipher and doesn't need any comments to sort out. It's something I personally find just too murky to understand for complex stuff. If you need comments, in my opinion, it's probably best to use an IF structure and lay out those comments at the various blocks as you've did with the original code.
Your future self will thank you.
At least, mine usually does. 
'IF n.ac THEN ' If note enharmonic
' IF Vtog%(shrp_flt) THEN ' If in flat mode
' NoteName$ = n.bf
' ELSE ' If in sharp mode
' NoteName$ = n.bs
' END IF
'ELSE ' If note NOT enharmonic
' NoteName$ = n.nt
'END IF
Things are spread out on multiple lines and each segment is commented to help understand what it's supposed to be doing. I'd personally find the above much easier to maintain and work with after a 6 month break, where I might find myself having to go back and rework the code for some error or new enhancement, than I would the _IFF alternative.
NoteName$ = _IIF(n.ac, _IIF(Vtog%(shrp_flt), n.bf, n.bs), n.nt)
There's a lot less code there for you to write and work with, but also a lot less explanation of what's going on with that code. It's just user defined types which you might not remember what every element stands for in the future, and arrays and indexes, and... a huge question mark which says, "WTF WAS THIS DOING?!!"
It may save you a few bytes disk space and compact the code down a byte or two, but you have to consider if it's going to be worth the hit to readability and maintenance with the future of the code. Over the years, I've thrown together a LOT of quick and sloppy code, and been proud of it at the time, only to have to almost rewrite the whole thing from scratch a couple years later just because I couldn't figure out my own damn flow and logic with stuff. LOL!
My opinion with _IFF is that it's convenient, but it's a tool that I'd personally tend to use for fairly obvious stuff which isn't hard to decipher and doesn't need any comments to sort out. It's something I personally find just too murky to understand for complex stuff. If you need comments, in my opinion, it's probably best to use an IF structure and lay out those comments at the various blocks as you've did with the original code.
Your future self will thank you.
At least, mine usually does.