lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 784ccff 1/4: Prefer 'n_'- prefix for "num


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 784ccff 1/4: Prefer 'n_'- prefix for "number of"
Date: Wed, 23 May 2018 19:36:49 +0200

On Wed, 23 May 2018 12:25:26 -0400 (EDT) Greg Chicares <address@hidden> wrote:

GC> branch: master
GC> commit 784ccfff8ff53f553715c59d37f29a26fb49965c
GC> Author: Gregory W. Chicares <address@hidden>
GC> Commit: Gregory W. Chicares <address@hidden>
GC> 
GC>     Prefer 'n_'- prefix for "number of"

 I think it goes without saying that "n_" is much less readable (and, at
least for me, also less writable: I'm sure I'll automatically use "num_"
the next time, in spite of all my efforts to rememeber not to do it...)
than "num_", so what could possibly the reason for selecting this prefix
instead of "num_"? I can, of course, see the gain of 2 characters, but can
this be really the only thing?

 Sorry if I'm sounding too negative (FWIW I appreciate the other changes
you made in this push, but I'm just not commenting on them), but this looks
like an unambiguous regression to me. With "num_" the code was readable and
clear. With "n_" the code might remain clear in the places where the
variable meaning is absolutely obvious anyhow (i.e. it could be called "z"
and it still wouldn't hurt the readability), but not all in all the other
ones.

 There was an almost equal number of the lines of code using "n_foo" (115)
and "num_foo" (97) before this change and I would have definitely preferred
if the former could be changed to the latter rather than vice versa. Also
consider that "n_" prefix doesn't always mean "num_", see e.g. "n_a" in
ihs_avdebug.cpp, "n_d_c" in value_cast_test.cpp or the strings (!)
"n_classes" and "n_cells" in multiple_cell_document.cpp.

 Is there any chance of reverting this change and, perhaps, doing the one
in the other direction?
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]