Hi Akim,
(A) > I'm looking for means to avoid repetitions, and boilerplate.
It needs to be balanced against the other characteristics of maintainability.
Two important aspects are:
(B) Making the code easy to understand.
(C) Making it easy to find all definitions and all references of an
identifier.
One of the main tricks to avoid boilerplate is to create identifiers by
concatenation. For example, the variable GNULIB_ISWBLANK gets assigned through
gl_WCTYPE_MODULE_INDICATOR([iswblank]), which is not obvious. And in
gnulib-common.m4, it looks like _GL_ATTR_deprecated is never used. But in
fact, it is - though _GL_HAS_ATTRIBUTE. Such constructs avoid boilerplate,
but they make it hard to find all references of the identifiers.
On the other hand, what are the drawbacks of repetitive code?
- Typos? Hardly. The maintainer should not type every identifier, but instead
use copy&paste or use query&replace on a template.
- Difficult to grasp? Only if the indentation and comments don't help.
- Too long to read? People now use editor windows with more than 50 rows.
In Lisp, the means of choice to avoid repetitions and boilerplate are the
macros. When I was at university, I loved macros (like DEFSTRUCT and DEFCLASS
in Lisp) that expand to interesting code. Until I realized that this works only
because
- DEFSTRUCT and DEFCLASS have a detailed specification regarding the input
syntax and their effects,
- most Lispers already know DEFSTRUCT and DEFCLASS, thus it does normally
not present much of a learning curve.
Until the day I had to debug a complex invocation of a complex, hand-crafted,
scarcely documented macro. I even had an IDE that showed me the result of the
macro-expansion when I modified the input; nevertheless, since then, I tend
to value (B) and (C) as more important than (A).
Bruno
