In general, I agree. But I have a situation that is prompting me in the automated direction.
I have a list of triggers, ⌥⌘A through ⌥⌘Z that I originally started with, as potential hotkeys to switch to different desktops. I deliberately left out ⌥⌘Q and ⌥⌘W because of their nearly universal and annoying side effects if they aren't caught by KBM. I also wanted the keys to be mnemonic, so I still haven't used "J" but "K" was one of my first ones, for my KBM desktop. Over time I have been adding shifted versions of them, e.g.,⌥⇧⌘K became my KBM "meta" desk, for Forum research and AppleScript testing.
Because of the nature of how additions are made to the KBM Triggers list, all the shifted triggers are now at the bottom of the list and they are not in alphabetical order. Recently I added ⌥⇧⌘A for a second Admin desktop so now ⌥⌘A is at the top and ⌥⇧⌘A is at the bottom of a list of 36 triggers. My aesthetics rebell. Clean code should be readable, organized, and even beautiful, if possible. To clean it up would mean over ten minutes of tedium, retyping the list in the new order, and future changes would have to be done all over again, so I'm spending up to 10 hours seeing if I can program it, because for me the programming — and the learning that comes along with getting the programming to work — is fun (most of the time).
For instance, to replace the list of triggers, I am pretty sure that I have to first delete the existing list of triggers, one by one. In AppleScript, I got the list of triggers from KBM and stepped through the list, deleting them one at a time. But there was a knotty problem. If I had a test list of four triggers, the loop would delete two of them. If I made a test list of eight triggers, the loop would delete four of them. WTH?
I finally figured out that AppleScript was creating the list of triggers and then stepping through its internal list to execute the deletions. So with four triggers, it deletes trigger 1 and then the list shifts so that when it deletes trigger 2, it's actually deleting trigger 3. Then it attempts to delete trigger 3, but there is no trigger 3, so it quits. In a list of 36 triggers, it would presumably delete every odd trigger until it had deleted 18 of them — not my intent.
I am sure there is a simple AppleScript option/flag to process the list in reverse order, so as soon as I find that, I presume this step will be done and I can move onto the next step.
I think both of those will be simple, although actually coding the dictionary/look-up table for the key codes may take some creative use of VIM and SED or some such.
I am definitely not going to bother with this stuff in the first (or even second) pass.