[gdal-dev] Starting a discussion on style and coding guidelines

[Kurt Schwehr]

Please fork the 80 col style guide to a new thread.  Yes, there are lots of
issues with the coding style, but can we do one thing at a time?  If you
are really motivated, why not write a proposal like mine and talk through
the issues of different column constraints (there are good reasons for the
many different ways and related issues).  Then start a new thread with it.

On Mon, May 9, 2016 at 9:43 AM, Joaquim Luis <jluis at ualg.pt> wrote:

>
>
> I like one statement per line because it helps walking through the code
>> with gdb; you can see the whole statement that is going to be executed.
>>
>
> Fully agree, and my example respects that.
>
>
> I also share the idea that seeing a whole subroutine or a logical part at
>> once helps understanding the code.
>>
>> Ari
>>
>> 09.05.2016, 18:14, Joaquim Luis kirjoitti:
>>
>>> Hi,
>>>
>>> There is one aspect of the coding style that I honestly do not
>>> understand. Why continuing to recommend the 80 chars line width? I don't by
>>> the readability argument, well on the contrary, if because of it the result
>>> is an excess 'verticalization' of the code it becomes much harder to read.
>>>
>>> I don't know for you guys but when I'm forced to permanently scroll up
>>> and down it becomes really much harder to study a code. For me the ideal is
>>> that a function holds in a single screen size, but ofc without piling up
>>> everything to reach that goal.
>>>
>>> A little example from gdaldem_lib.cpp (line 240)
>>>
>>> ****************** Current code *********************************
>>>
>>>     for ( i = 0; i < 2 && i < nYSize; i++)
>>>     {
>>>         if( GDALRasterIO(   hSrcBand,
>>>                         GF_Read,
>>>                         0, i,
>>>                         nXSize, 1,
>>>                         pafThreeLineWin + i * nXSize,
>>>                         nXSize, 1,
>>>                         GDT_Float32,
>>>                         0, 0) != CE_None )
>>>         {
>>>             eErr = CE_Failure;
>>>             goto end;
>>>         }
>>>     }
>>> ******************************************************************************
>>>
>>> ************ What I think would be reasonable
>>> ********************************
>>>
>>>     for (i = 0; i < 2 && i < nYSize; i++) {
>>>         if (GDALRasterIO(hSrcBand, GF_Read, 0, i, nXSize, 1,
>>> pafThreeLineWin + i * nXSize, nXSize, 1,
>>>                          GDT_Float32, 0, 0) != CE_None ) {
>>>             eErr = CE_Failure;
>>>             goto end;
>>>         }
>>>     }
>>> ******************************************************************************
>>> 7 lines instead of 15, and is it less readable (in a text editor, not in a
>>> mail client)?
>>>
>>> Joaquim
>>>
>>> On 9 May 2016 at 09:15, Ari Jolma <ari.jolma at gmail.com> wrote:
>>>>
>>>>> 05.05.2016, 01:30, Kurt Schwehr kirjoitti:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> If you've been watching the timeline on trac, you have probably seen a
>>>>> large
>>>>> number of cleanup CLs from me.  It's definitely past time to get some
>>>>> discussion going on these changes.  If the community likes these, we
>>>>> can add
>>>>> them to rfc8_devguide.
>>>>>
>>>>>
>>>>> It is very minimal right now. Good style guides tend to be quite large,
>>>>> e.g., https://google.github.io/styleguide/cppguide.html or
>>>>> http://geosoft.no/development/cppstyle.html
>>>>>
>>>>
>>>> Good C++ guidelines that fit on a single page is all you need
>>>> these days, after Bjarne Stroustrup
>>>> https://parasol.tamu.edu/people/bs/622-GP/C++11-style.pdf
>>>>
>>>> Best regards,
>>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160509/f80a785f/attachment.html>