[osg-users] [ANN] Cross-platform examples for Linux, macOS, Windows, Android, iOS, and Web

[michael kapelko]

Hi, Robert.

I agree with you that explicit usage of `this` is not something I see
frequently myself. That's a valid point. I've been on that side, too.
Probably, because I never asked myself about `this`.

My work is related to iOS development, so I've seen Apple ecosystem
migration from Objective-C to Swift. Objective-C requires `self` (aka
`this`), however, Swift does not. There have been debates about `self`
in Swift, too: https://github.com/raywenderlich/swift-style-guide/issues/7
This migration is what made me wonder if using `this` in C++ and
`self` in Swift has benefits.

I'd like to bring a few more thoughts why `this` is better than `_`,
`m`, or `m_`:
* altering variable names to reflect environment (member / local)
always seemed inappropriate to me
* `_`, `m`, or `m_` is really just a shortcut for using `this`

So, since everybody else was already distinguishing local variables
from memeber ones with some sort of Hungarian notation, I just tried
to be honest and use facilities provided by the language itself:
`this` pointer.
In case I find a serious drawback that would cost me hours of
development time, I would definitely go back to `this`less approach.
But so far I've seen no problem with `this` approach.

On Wed, 26 Sep 2018 at 17:17, Robert Osfield <robert.osfield at gmail.com> wrote:
>
> Hi Michael,
>
> On Wed, 26 Sep 2018 at 09:16, michael kapelko <kornerr at gmail.com> wrote:
> > I started to use explicit `this` to simplify reading and increase
> > "shareability" of code:
>
> Doing something that very few other developers do is likely to reduce
> "shareability", I'm experienced engineer and read lots of third party
> code and found myself wondering why the code was different.
>
> > * I don't need to rely on IDE to highlight member or local
> > variables/functions for me, so I can get away with simpler and faster
> > tools (VIM, in my case)
> > * I can paste such code blocks anywhere, and a reader won't need to
> > run IDE to know this is member or local variable/function/etc.
>
> If the code is well written then it should be relatively clear what a
> global functions and what a local method calls.  Most modern C++
> programs have few global variables and functions so if you see a
> function call it's generally safe to assume it's a local method, for
> variables then it's most likely the variable is a local or member
> variable.  For the OSG we just prefect with _ to make it clear it's a
> member variable rather than global, other codebases use m_ or keep the
> class/structs simple enough that it's clear.  Personally I don't use
> m_ as I find it distracting and reduces the flow of readability, and
> find this-> is even more verbose and distracting.
>
> > So far this approach looks better to me. When I see code referencing
> > member variables/functions without `this`, I need to know what
> > particular color IDE uses to tell member/local variables apart. And to
> > make things more complicated, different IDEs use different colors :)
>
> this-> is a lot of typing you keep having to do just to make your code
> intentions clear.  Developers are used to code without it and should
> be able to work out what is local or member variable/functions pretty
> easily if the class/structs are kept straight forward and the member
> function kepts small enough that you can see where local variables are
> being written.
>
> As for different IDE's doing different things.  Personally the first
> stop should be making the code clear enough that these bells and
> whistles aren't required, and if they are added then the developer
> will likely be just using one IDE for majority of their work and
> shouldn't end up confused.
>
> Personally I don't use IDE's, I just use the KDE kate editor and read
> the class interfaces and implementations, it does highlighting of many
> things by not discriminating between member vs local variables etc.  I
> don't have particular issues trying to read code.
>
> When writing code for others to digest I think it is probably best to
> avoid doing things that are unusual, and as a good practice the
> CppCoreGuindelines are probably a good place to start as any.
>
> Cheers,
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org