On the back of my recent post on writing bug-less code I wanted to raise a few suggestions (to ISC) that would help prevent certain types of bugs at compile time. I've probably missed a few, but these are the main ones in my mind. Please contribute more suggestions.
Btw, these also serve as potential gotchas for new COS developers.
I except that introducing these types of changes can cause legacy code problems. Particularly where developers do some interesting overloading of method arguments.
Does anyone NOT use a debugger? I can't remember the last time I did. It's not because I don't dislike them, I just don't need to use them. The main reason for this is because I have a certain development methodology that either produces less bugs, catches them at a unit test level, or makes tracking them down much easier.
Here are my tips...
1. Write your own COS cheat-sheet.
This is mainly for anyone that is new to COS. One of the biggest bug hazards is not knowing how certain commands and functions work.
Inspired by the article "Declarative development in Caché" that's still trending on the dev com. The OP explored a functional style of iterating over a collection. A comment today suggested "Caché would need syntax support for anonymous functions".
With Macros you can kind of get anonymous like syntax using dot notation.
This is not production code, but it does work. First the macros...
#Define foreach(%c,%l) for i=1:1:%c.Size set %l=%c.GetAt(i) do #Define map(%oc,%nc,%l) set %nc=##class(%ListOfDataTypes).%New() for i=1:1:%oc.Size set %l=%oc.GetAt(i) do do %nc.Insert(fpl8349312378) #Define filter(%oc,%nc,%l) set %nc=##class(%ListOfDataTypes).%New() for i=1:1:%oc.Size set %l=%oc.GetAt(i) set fpl8349312378="" do if fpl8349312378'="" do %nc.Insert(fpl8349312378) #Define reduce(%oc,%res,%l) set %res="" for i=1:1:%oc.Size set %l=%oc.GetAt(i) do set %res=fpl8349312378 #Define return(%val) set fpl8349312378=(%val) quit