[gdal-dev] Refactoring: class members clean-up

[Kurt Schwehr]

I personally like foo_, but m_ is fine.  I worry about unexpected side
effects of changing member naming with private members.  I don't think
there will be any if everything builds, but I still worry.  If we go for
changing publics, we should pick a time and go for a major version number
bump and expect a lot of peopIe using GDAL to go through a lot of pain.  I
see a lot of stuff generally like this...

class Foo
{
public:
  Foo(int blahIn) { this->blah = blahIn; };
  int blah;
}

After looking at a lot of GDAL code, it seems that we should go with:

class Foo
{
  int m_blah;
public:
 Foo( int blah ) : m_blah(blah) {}
 int blah() { return m_blah; }
}

On Fri, Oct 16, 2015 at 4:50 PM, Mateusz Loskot <mateusz at loskot.net> wrote:

> On 16 October 2015 at 22:47, Even Rouault <even.rouault at spatialys.com>
> wrote:
> >
> >> I'm not proposing any changes to naming convention. AFAICT, currently
> GDAL
> >> either uses m_ prefix or nothing.
> >
> > Well, I think you'll agree that using m_foo or bla_ is a naming
> convention,
>
> Right, I meant, to actually apply unified convention: some classes use
> no prefix,
> others use m_. Let's choose m_ and stick to it.
>
> > and there's nothing specified in
> > https://trac.osgeo.org/gdal/wiki/rfc8_devguide related to that.
>
> Then, it's gonna be updated, I think.
>
> Best regards,
> --
> Mateusz  Loskot, http://mateusz.loskot.net
> _______________________________________________
> 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/20151016/69a01e06/attachment.html>