[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave line length
From: |
Rik |
Subject: |
Re: Octave line length |
Date: |
Wed, 15 Jan 2020 10:37:05 -0800 |
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
- Re: Octave coding conventions, Rik, 2020/01/13
- Re: Octave coding conventions, John W. Eaton, 2020/01/13
- Re: Octave line length, Rik, 2020/01/13
- Re: Octave line length, Andrew Janke, 2020/01/13
- Re: Octave line length, John W. Eaton, 2020/01/14
- Re: Octave line length, Rik, 2020/01/14
- Re: Octave line length, John W. Eaton, 2020/01/14
- Re: Octave line length, Rik, 2020/01/14
- Re: Octave line length, John W. Eaton, 2020/01/15
- Re: Octave line length,
Rik <=
- Re: Octave line length, Kai Torben Ohlhus, 2020/01/14