Re: [Boost-gil] Preferred line length

Subject: Re: [Boost-gil] Preferred line length
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-04-11 20:22:27

On 11 April 2018 at 22:05, Stefan Seefeld <stefan_at_[hidden]> wrote:
> On 04/11/18 15:51, Mateusz Loskot wrote:
>>
>> Can we try to settle the preferred line length in GIL source code?
>>
>> Current style varies from file to file, even from chunk to chunk
>> within a single file. Often, there are unindented lines,
>> overdose of whitespaces, etc.
>
>
> I agree this can be annoying, so it might be useful to use some established
> conventions.
> Both of the issues you name (max line length and amount of indentation) are
> related and important to settle.

Good.

> But, while we should really agree on indentation (this can be easily
> configured in nowadays editors), I'm less sure about hard limits for line
> length, given that there is a tradeoff to optimize for code readability.
>
> Do you have suggestions for these parameters ?

I copied the Spirit and Geometry as examples of such suggestions.
I'd prefer to fit between 80-90.

> (For indentation I'd vote for 2 spaces (replace all tabs by spaces !),

I'd vote for 4 spaces. No tabs!

I find Spirit code layout pretty clean
https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/qi/parse.hpp#L124-L135
and Geometry adopted similar approach
https://github.com/boostorg/geometry/blob/develop/include/boost/geometry/core/point_type.hpp#L94-L112

I'd prefer to not to indent namespace block though, as Spirit does.
If we also avoid too much of whitespace after/before (,),<,>, then
80-char line should work well.

> for max line length I can be easily
> convinced to settle on anything between 78 and 90 characters.)

We agree here.

>> I know this may not be the right moment to attempt style refactoring,
>> but I think it would be nice to have at least some style reference
>> that will hold in future.
>
> Right. I think it would be useful to establish a convention, then we can
> make sure that any code we touch to fix bugs or add features adheres to
> them. No global restyling required.

Exactly!

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net