Re: Octave line length

[Rik]

On 01/15/2020 08:32 AM, John W. Eaton wrote:
> On 1/14/20 11:25 AM, Rik wrote:
>> On 01/13/2020 09:20 PM, John W. Eaton wrote:
>
>>> Is it easy to ask the reformatting tool to not break any expressions into
>>> multiple lines and then get a distribution of line lengths for all
>>> lines?  I think it would be interesting to see just how many lines are
>>> longer than 80, 90, 100, ... characters.
>>
>> I don't know how to do it with a reformatting tool, but with Perl it was
>> easy enough.  The following results are only for liboctave/ and libinterp/
>> including all *.cc, *.c, *.h files.  The line length begins at 1 because
>> the newline is counted as a character.
>
> I did the following:
>
>   echo "LENGTH  COUNT"; for f in $(hg locate '*.c' '*.f' '*.cc' '*.h'
> '*.ll' '*.yy'); do awk '{ n = length ($0); if (n > 80) print n; }' $f ;
> done | sort | uniq -c | awk '{printf (" %4d   %4d\n", $2, $1); }' | sort -n
>
> and my results are a little different from yours.

The differences are unlikely to change the conclusions.  I didn't include
"*.ll", "*.yy", or "*.f" files.  There are only two "*.ll" and two "*.yy"
files so they can't skew the result to much, and I didn't include Fortran
files at all because I wasn't sure it was appropriate to use coding
conventions for C/C++ files on that language.

>
> Using
>
>   for f in $(hg locate '*.c' '*.f' '*.cc' '*.h' '*.ll' '*.yy') ; do awk
> '{if (length ($0) > 100) print FILENAME; }' $f ; done | sort | uniq -c |
> sort -nr
>
> to get counts by file for lines longer than 100 characters, I see
>
>     199 liboctave/external/Faddeeva/Faddeeva.cc
>     141 libinterp/operators/op-int.h
>      72 liboctave/numeric/lo-specfun.h
>      70 libinterp/corefcn/besselj.cc
>      54 libgui/src/gui-preferences-sc.h
>      24 libgui/qterminal/libqterminal/unix/Filter.h
>      23 libinterp/corefcn/data.cc
>      22 libinterp/corefcn/graphics.in.h
>      19 libgui/src/settings-dialog.cc
>      18 libinterp/dldfcn/qr.cc
>      18 libinterp/corefcn/rand.cc
>      14 libinterp/corefcn/mappers.cc
>      12 libinterp/octave-value/ov-java.cc
>      11 libinterp/corefcn/graphics.cc
>      10 liboctave/numeric/oct-rand.cc
>      10 libinterp/corefcn/matrix_type.cc
>      10 libgui/src/welcome-wizard.cc
>
>
> I bet a bunch of those are long error messages.

Clearly a power law sort of thing.  The total number of long lines is
1,061.  But files with < 10 long lines only contribute 334 lines to the
total.  Taking care of the 14 files at the start would cover 727/1061 =
68.5% of the instances.

>
> The thing I'm really curious about is how many lines longer than N (say
> 100 or 132) characters do we have if we reformat the sources so that no
> expressions are split across lines?  Do things get any worse than what we
> currently have, or would most of of the expressions that are split to fit
> in 80 character lines fit in 100 or 132 character lines?
>
This is hard to accurately judge.  I worked up a Perl script that checked
for lines which did not end in a ';' or ')' character.  If they did not, it
joined the following line to the existing line and checked the length. 
Checking only the *.cc files showed more than 2,000 new lines which would
be > 100 characters.  As an example, errors and warning in liboctave/ such
as this

        (*current_liboctave_warning_with_id_handler)
          (warning_id_nearly_singular_matrix,
           "matrix singular to machine precision, rcond = %g", rcond);

become

        (*current_liboctave_warning_with_id_handler)
          (warning_id_nearly_singular_matrix,"matrix singular to machine
precision, rcond = %g", rcond);

In general, since we have tried to keep things below 80 characters, joining
two long lines is going to be roughly 160 characters - indent and the
indent is rarely more than 28, so even a large limit like 132 is insufficient.

--Rik