Re: [lmi] [lmi-commits] master 9e360f0 2/5: Make future copyright updates easier

[Vadim Zeitlin]

On Sun,  3 Jan 2021 08:07:11 -0500 (EST) Greg Chicares 
<gchicares@sbcglobal.net> wrote:

GC> branch: master
GC> commit 9e360f003b9795b980cd0b762e4de182d27b59f8
GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> 
GC>     Make future copyright updates easier
GC>     
GC>     * GNUmakefile: Handle hooks/ subdirectory as well. Mark end of each
GC>       list of potential issues, for readability. Improve some regexes.
GC>     * test_coding_rules.cpp: Avoid false positives by writing "Copyright"
GC>       using string-literal concatenation.
GC>     * wx_test_about_version.cpp: Likewise.

 I don't know how to say it politely, but I find the workarounds for the
last 2 bullet points rather ugly and I think there are at least 2 other
ways to do better:

1. Just exclude the known good "Copyright" appearances when checking for
   unutterable terms. This is simple to do and would be best IMO as the
   checks should help keep the code tidy instead of making it less tidy
   than it could be (I feel like there should be some relationship to
   Campbell's law here).

2. Define a constant using the "C""opyright" workaround once in some
   header, with a comment explaining why is it defined like this and why
   does it exist in the first place (because finding this string in the
   code without any explanations is really not great) and use this constant
   in the other places. Using some unique, and ideally self-explanatory,
   name for the constant (such as TABOO_COPYRIGHT_STRING) would give the
   readers of the code a fighting chance to figure out why is it there.

 Of course, I could provide patches for either (1) or (2) if you agree to
do it like this -- please let me know if you do.

 Thanks,
VZ

pgpfgr2nAhvUT.pgp
Description: PGP signature