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.osfi...@gmail.com> wrote: > > Hi Michael, > > On Wed, 26 Sep 2018 at 09:16, michael kapelko <korn...@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@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org