This, in my view, is why the many practices I’ve seen proposed as rules for clear code are fragile guides at best. In æsthetics it is helpful to distinguish principles, and futile to legislate.
exposed-infrastructure/ sets out the basic picture.Many q keywords are simple wrappers. They are defined to make the language more approachable. It is tempting to regard them as ‘trainer wheels’ to be discarded on graduation. But ‘good q style’ is to use them: to write sum and raze rather than +/ or ,/.Recommended stylistic practices sometimes conflict, and must be weighed against the intent to write clearly. For example, prefix and infix syntax is preferred to bracket notation: less ‘visual noise’. The each keyword iterates a unary, so count each x is better than count'[x]. But combinations of iterators are usually best written concisely, so count'''[x] is clearer than((count each)count each) each xWhy? Arthur Whitney refers occasionally to “Three Principles of Coding Clarity” – might provide some insight.This, in my view, is why the many practices I’ve seen proposed as rules for clear code are fragile guides at best. In æsthetics it is helpful to distinguish principles, and futile to legislate.HTHStephen
Tel: +44 (0)28 3025 2242
Tel: +1 (212) 447 6700
Tel: +61 (0)2 9236 5700