On Sunday, 20 September 2020 at 20:46:42 UTC, mate wrote:
> Interesting. How long are your longest lines?

$ cat $(git ls-files '*.d') | awk '{print length}' | sort -rn | head
3036
826
826
819
793
610
593
568
488
488


lol, but I'd note that's almost certainly skewed by documentation comments, which I usually let automatically word-wrap (and if you don't, you should btw, it is so so so so so much nicer to work with).

Of the 156,000 lines though:

400 are > 180. (0.3%, likely documentation paragraphs)
1,600 are between 120 and 180. (1%, likely docs again)
7,700 are between 80 and 120. (5%, more likely actual code)

The remainder are < 80. (94%)


I did NOT convert tabs to spaces for this.

On Sunday, 20 September 2020 at 21:13:53 UTC, Adam D. Ruppe wrote:
> On Sunday, 20 September 2020 at 20:46:42 UTC, mate wrote:
>> Interesting. How long are your longest lines?
>
> $ cat $(git ls-files '*.d') | awk '{print length}' | sort -rn | head
> 3036
> 826
> 826
> 819
> 793
> 610
> 593
> 568
> 488
> 488
>
>
> lol, but I'd note that's almost certainly skewed by documentation comments, which I usually let automatically word-wrap (and if you don't, you should btw, it is so so so so so much nicer to work with).
>
> Of the 156,000 lines though:
>
> 400 are > 180. (0.3%, likely documentation paragraphs)
> 1,600 are between 120 and 180. (1%, likely docs again)
> 7,700 are between 80 and 120. (5%, more likely actual code)
>
> The remainder are < 80. (94%)
>
>
> I did NOT convert tabs to spaces for this.

Thanks. So it does look like you have an implicit soft line length limit for code, but not documentation.

On Sunday, 20 September 2020 at 21:42:54 UTC, mate wrote:
> Thanks. So it does look like you have an implicit soft line length limit for code, but not documentation.

Well, it isn't so much a limit as just a lack of demand or some other kind of natural traffic calming.

This makes me think about cities. Locally, the city planning department has been doing a "road diet". They are changing the designs of roads to make them narrower, planting more trees, and other changes that just generally make them more difficult to navigate in an effort to make them safer.

It might sound weird that a strait path with a narrow gate would make the road safer, but it has been proven to have that positive safety effect because it makes drivers more likely to naturally slow down and pay attention. Whereas a posted speed limit on a wide, straight road is just a suggestion you only really think about when you see a police car, the designed-in "speed limit" created by trees, curves, narrowness, obstacles, etc. are something you think about for pure self-preservation if nothing else. At that point, you don't really need a legislated/posted speed limit at all (though you might keep one anyway just in case there is a particularly reckless or inexperienced driver who needs the tip, it would rarely actually need active enforcement).


Well, to bring this back to code, excessively long lines are already disincentivized by design. There's really no need in the majority of cases, and when there is, the natural benefits of two-dimensional layout (and the fact so many programming tools are line-based anyway) create an incentive for the author - for their own self-interested benefit - to break it up as appropriate. They don't have to be TOLD to by some kind of rubocop.

And if they choose to not break it up, it is probably because they judged it to not actually be a benefit in this case and someone complaining about the line length is more likely to be seen as patronizing than helpful.

On 9/20/20 4:46 PM, mate wrote:
> On Sunday, 20 September 2020 at 16:11:44 UTC, Adam D. Ruppe wrote:
> 
>> Like I said, it is probably meaningless, but a bit amusing since I'm so staunchly anti line length limits... but it seems to converge around the same length anyway.
> 
> Interesting. How long are your longest lines?
> 
> awk '{print length}' | sort -rn | head

Ah, interesting test. I just ran this modified script against phobos:

awk '{print length " " FILENAME}' $(git ls-files '*.d') | sort -rn

These are all lines longer than 120 characters. Not too bad.

215 std/functional.d
199 std/signals.d
180 std/experimental/allocator/package.d
169 std/experimental/allocator/building_blocks/region.d
163 std/experimental/allocator/building_blocks/region.d
163 std/experimental/allocator/building_blocks/region.d
162 std/signals.d
162 std/experimental/allocator/building_blocks/region.d
162 std/experimental/allocator/building_blocks/region.d
160 std/experimental/allocator/building_blocks/bitmapped_block.d
154 std/experimental/allocator/building_blocks/package.d
154 std/experimental/allocator/building_blocks/ascending_page_allocator.d
153 std/experimental/allocator/building_blocks/region.d
152 std/experimental/allocator/building_blocks/region.d
150 std/windows/registry.d
149 std/socket.d
147 std/range/package.d
147 std/format.d
145 std/digest/sha.d
144 std/internal/digest/sha_SSSE3.d
142 std/experimental/allocator/building_blocks/bitmapped_block.d
142 std/experimental/allocator/building_blocks/bitmapped_block.d
138 std/variant.d
138 std/range/package.d
137 std/internal/math/gammafunction.d
137 std/digest/murmurhash.d
136 std/experimental/allocator/building_blocks/free_list.d
136 std/algorithm/comparison.d
135 std/signals.d
134 std/numeric.d
134 std/experimental/allocator/building_blocks/free_tree.d
133 std/experimental/allocator/mallocator.d
131 std/signals.d
130 std/process.d
129 std/experimental/allocator/building_blocks/region.d
129 std/experimental/allocator/building_blocks/region.d
129 std/experimental/allocator/building_blocks/affix_allocator.d
127 std/socket.d
127 std/range/package.d
127 std/exception.d
126 std/windows/registry.d
126 std/range/package.d
126 std/experimental/allocator/typed.d
126 std/experimental/allocator/mallocator.d
125 std/regex/package.d
125 std/process.d
125 std/internal/math/biguintcore.d
124 std/uni/package.d
124 std/signals.d
124 std/regex/internal/ir.d
124 std/random.d
124 std/internal/math/gammafunction.d
123 std/signals.d
122 std/net/isemail.d
122 std/experimental/allocator/building_blocks/scoped_allocator.d
122 std/array.d
122 std/algorithm/iteration.d
121 std/typecons.d
121 std/socket.d
121 std/signals.d
121 std/exception.d
121 std/exception.d
121 std/bitmanip.d

On Thursday, 17 September 2020 at 18:15:32 UTC, Andrei Alexandrescu wrote:
> On 9/17/20 1:49 PM, jmh530 wrote:
>> On Thursday, 17 September 2020 at 17:16:42 UTC, Andrei Alexandrescu wrote:
>>> [snip]
>
> I was all in favor of that, until I had to refactor a dozen two-liners consisting of... let me paste some code:
>
> auto put(ref GGPlotD gg, GeomBar def) {
>     import ggplot.backend.ggplot.geom_bar : geomBar;
>
>     return gg.put(geomBar(def));
> }
>
> And so it goes for pages.
>
> There is something to be said about a guideline versus a mindless dogma. Things like enum strings, each, and autodecoding are more of the latter.

A general comment on this thread. Each of us has his preferred code style guidelines (standards are great, everyone should have their own standards!). What we have done is we have trained our visual system / brain to easily pick out the semantically important information based on the styling/layout of the code. This leaves us feeling good or bad about certain formatting styles, depending on how well your trained visual system/rules can cooperate with the the style of the code at hand. Then we say that python-style indents stink, K&R brackets are the only way to go etc., etc.

In reality we need to agree to a single standard for D code and everyone has to stick to it whether it panders to the style of their choice or not. After a month or two our visual cortex / D brain will accommodate the new style and all will be well again in the world.

On Monday, 21 September 2020 at 00:19:28 UTC, Andrei Alexandrescu wrote:
> On 9/20/20 4:46 PM, mate wrote:
>> [...]
>
> Ah, interesting test. I just ran this modified script against phobos:
>
> [...]

stdx.allocator seems overrepresented doesn't it?

On Monday, 21 September 2020 at 11:21:50 UTC, mate wrote:
> On Monday, 21 September 2020 at 00:19:28 UTC, Andrei Alexandrescu wrote:
>> On 9/20/20 4:46 PM, mate wrote:
>>> [...]
>>
>> Ah, interesting test. I just ran this modified script against phobos:
>>
>> [...]
>
> stdx.allocator seems overrepresented doesn't it?

nice shot.

On Monday, 21 September 2020 at 11:26:40 UTC, DlangUser38 wrote:
> On Monday, 21 September 2020 at 11:21:50 UTC, mate wrote:
>> On Monday, 21 September 2020 at 00:19:28 UTC, Andrei Alexandrescu wrote:
>>> On 9/20/20 4:46 PM, mate wrote:
>>>> [...]
>>>
>>> Ah, interesting test. I just ran this modified script against phobos:
>>>
>>> [...]
>>
>> stdx.allocator seems overrepresented doesn't it?
>
> nice shot.

Hey that was not my intention!

On Monday, 21 September 2020 at 11:43:48 UTC, mate wrote:
> On Monday, 21 September 2020 at 11:26:40 UTC, DlangUser38 wrote:
>> On Monday, 21 September 2020 at 11:21:50 UTC, mate wrote:
>>> On Monday, 21 September 2020 at 00:19:28 UTC, Andrei Alexandrescu wrote:
>>>> On 9/20/20 4:46 PM, mate wrote:
>>>>> [...]
>>>>
>>>> Ah, interesting test. I just ran this modified script against phobos:
>>>>
>>>> [...]
>>>
>>> stdx.allocator seems overrepresented doesn't it?
>>
>> nice shot.
>
> Hey that was not my intention!

NVM The effect is the same. stdx.allocator is moslty written by Andrei.

On 9/21/20 7:48 AM, DlangUser38 wrote:
> On Monday, 21 September 2020 at 11:43:48 UTC, mate wrote:
>> On Monday, 21 September 2020 at 11:26:40 UTC, DlangUser38 wrote:
>>> On Monday, 21 September 2020 at 11:21:50 UTC, mate wrote:
>>>> On Monday, 21 September 2020 at 00:19:28 UTC, Andrei Alexandrescu wrote:
>>>>> On 9/20/20 4:46 PM, mate wrote:
>>>>>> [...]
>>>>>
>>>>> Ah, interesting test. I just ran this modified script against phobos:
>>>>>
>>>>> [...]
>>>>
>>>> stdx.allocator seems overrepresented doesn't it?
>>>
>>> nice shot.
>>
>> Hey that was not my intention!
> 
> NVM The effect is the same. stdx.allocator is moslty written by Andrei.

Haha, nice. Actually quite a few people worked on the allocator, including a couple of my students. It's likely the long lines aren't mine - it's not how I write code.