<p dir="ltr">On 16 Oct 2015 19:30, "Even Rouault" <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>
> Le vendredi 16 octobre 2015 18:11:17, Mateusz Loskot a écrit :<br>
> > Hi,<br>
> ><br>
> > I noticed Kurt has been applying lots of non-functional code improvements,<br>
> > refactoring, and cleaning compilation warnings, etc.<br>
> ><br>
> > I have been considering similar clean-up also to unify class member names<br>
> > which often lead to compilation warnings due to declaration hiding.<br>
> ><br>
> > I committed a short example of such refactoring:<br>
> > <a href="https://trac.osgeo.org/gdal/changeset/31023">https://trac.osgeo.org/gdal/changeset/31023</a><br>
> ><br>
> > Would that be something acceptable across the whole source code?<br>
><br>
> I guess Kurt will point to<br>
> <a href="https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Variable_Names">https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Variable_Names</a><br>
> with the blabla_ convention ;-)<br>
><br>
> This underscore suffix convention is used in very few places, mainly the (old) KML driver AFAIK<br>
><br>
> The m_ convention is used a bit more often in the GDAL code base.</p>
<p dir="ltr">I'm not proposing any changes to naming convention. AFAICT, currently GDAL either uses m_ prefix or nothing.<br>
I will keep using g the m_ prefix, so the trailing underscore is out of discussion from my point.</p>
<p dir="ltr">> If we adopt any convention, this should be added to <a href="https://trac.osgeo.org/gdal/wiki/rfc8_devguide">https://trac.osgeo.org/gdal/wiki/rfc8_devguide</a><br></p>
<p dir="ltr">I haven't checked the page but I assume it should be m_<br></p>
<p dir="ltr">> Personnaly I find the m_ convention more readable as the trailing underscore<br>
> is easy to miss, but perhaps that is the intention ?<br></p>
<p dir="ltr">My personal preference is the trailing underscore, but that is irrelevant as I'm going to follow the code base. <br></p>
<p dir="ltr">> Whatever convention would be used, I'd advise not to apply it to public or<br>
> protected members of GDAL exported classes (like the ones of gcore/gdal_priv.h),<br>
> because that could break external plugins. Or that would require more advertizing of the change.<br></p>
<p dir="ltr">Good point. OK.<br></p>
<p dir="ltr">> > I'm willing to join Kurt's efforts.<br>
><br>
> Some coordination might be required to avoid stepping on each other toes.</p>
<p dir="ltr">Sure. That's why I mentioned Kurt hoping he will chime in.<br></p>
<p dir="ltr">Mateusz Łoskot<br>
(Sent from mobile)</p>