Re: Octave line length

[Rik]

On 01/13/2020 09:20 PM, John W. Eaton wrote:
> On 1/13/20 5:18 PM, Andrew Janke wrote:
>>
>>
>> On 1/13/20 6:06 PM, Rik wrote:
>>> On 01/13/2020 11:30 AM, John W. Eaton wrote:
>>>> On 1/13/20 11:02 AM, Rik wrote:
>>
>>> With that in mind, I would suggest we stop enforcing an 80-character
>>> limit.  It isn't particularly important given that programmers are working
>>> on 25" HiDPI monitors these days.  Instead, what I value is the clarity of
>>> intent.
>>
>> Let's not go too long! Now that we have large monitors, some of us use
>> them to fit multiple editor and console windows side-by-side. A limit of
>> 80-100 lines is still useful in those cases. Also some of us are working
>> on 13" laptops.

This is why I said "large-ish" value, rather than no limit.  It is still
important to nudge programmers towards writing clear code.

> 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.

Line Length : Count

1: 82105
2: 15272
3: 9255
4: 8223
5: 1994
6: 13068
7: 5938
8: 4910
9: 1804
10: 7111
11: 2722
12: 4435
13: 3621
14: 5848
15: 3455
16: 4437
17: 4866
18: 5618
19: 5989
20: 5025
21: 4571
22: 6054
23: 5182
24: 5604
25: 4687
26: 4770
27: 5137
28: 4738
29: 3866
30: 4240
31: 4671
32: 5644
33: 4159
34: 4683
35: 4235
36: 5141
37: 4170
38: 3960
39: 5099
40: 3868
41: 3807
42: 3865
43: 3759
44: 3598
45: 3741
46: 3568
47: 3494
48: 4507
49: 3510
50: 4241
51: 3471
52: 4462
53: 3237
54: 3521
55: 3605
56: 3176
57: 5405
58: 3635
59: 3014
60: 2967
61: 3028
62: 4007
63: 2740
64: 3832
65: 4960
66: 3627
67: 2776
68: 2759
69: 7028
70: 2944
71: 2748
72: 2727
73: 4792
74: 6709
75: 2472
76: 2088
77: 1976
78: 1624
79: 1644
80: 1355
81: 990
82: 435
83: 404
84: 190
85: 163
86: 140
87: 95
88: 78
89: 121
90: 82
91: 97
92: 82
93: 65
94: 61
95: 38
96: 109
97: 68
98: 77
99: 45
100: 38
101: 43
102: 37
103: 37
104: 62
105: 40
106: 29
107: 22
108: 41
109: 23
110: 12
111: 18
112: 26
113: 17
114: 19
115: 20
116: 28
117: 10
118: 15
119: 11
120: 10
121: 16
122: 17
123: 14
124: 29
125: 11
126: 16
127: 19
128: 3
129: 7
130: 4
131: 3
132: 3
133: 4
134: 2
135: 7
136: 1
137: 1
138: 1
139: 1
141: 1
144: 1
145: 1
146: 1
147: 3
148: 4
149: 5
150: 1
151: 2
152: 7
154: 2
155: 1
157: 1
159: 2
160: 1
161: 1
163: 3
164: 2
165: 1
167: 1
170: 1
171: 1
189: 1
195: 1
202: 1
225: 1
237: 58
238: 37
239: 5
244: 5
245: 17
246: 2
247: 3
251: 1
277: 2
278: 1
279: 15
280: 6
281: 19
282: 4
312: 3
313: 2
314: 7
315: 7
316: 3
317: 1
384: 1
393: 1

The extremely long line lengths (> 200) should probably be checked and
dealt with.  I looked at one instance just to get an idea and it was

      return 0.11380523107427108222e0 + (0.43099572287871821013e-2 +
(0.36544324341565929930e-4 + (0.47965044028581857764e-6 +
(0.81819034238463698796e-8 + (0.17934133239549647357e-9 +
(0.50956666166186293627e-11 + (0.18850487318190638010e-12 +
0.79697813173519853340e-14 * t) * t) * t) * t) * t) * t) * t) * t;

This could easily be split, but it is in the file Faddeeva.cc which we
specifically do *not* use Octave coding conventions in so that we can more
easily merge changes from upstream.


Feeding the raw data in to Octave you can ask what line length is required
to include a certain fraction of the distribution.

empirical_inv ([0.9, 0.95, 0.98, 0.99, 0.995], hraw)
ans =

   68   74   78   80   85

The results do show the limit around 80 characters that we have been trying
to enforce.  In this case 99.5% of all lines are <= 85 characters.

I think trying something like 95 might be a good first step.

>
> > And I'll bet there's some old curmudgeons in the Octave
> > community still running on 80-column terminal emulators.
>
> Emulator?!?  I still have a Wyse CRT terminal!  (But it's in a box and I
> haven't used it in many years.)
>
> jwe
>

There is a histogram of developers as well.  I just don't imagine the
number who can *only* view 80 columns at a time is very large.

--Rik