Re: Coding standards proposal, usage of "this"

Lancelot SIX via Gdb-patches
2021-08-15T13:35:18Z

On Fri, Aug 13, 2021 at 10:26:48AM -0400, Simon Marchi via Gdb-patches wrote:
> Hi all,
>
> Here's something I had in mind for a while. We don't consistently use
> `this` when referring to fields or methods of the current object. I
> never now if I should use it or not, or point it out in review. I
> therefore propose these rules so that we have something to refer to.
>
> - Use `this` when referring to a data member that is not prefixed by
> `m_`. Rationale: without `this`, it's not clear that you are
> referring to a member of the current class, versus a local or global
> variable.
> - Don't use `this` when referring to a data member that is prefixed by
> `m_`. Rationale: the prefix already makes it clear that you are
> referring to a member of the current class, so adding `this` would
> just add noise.
> - Use `this` when referring to a method of the current class.
> Rationale: without `this, it's not clear that you are referring to a
> method of the current class, versus a free function.
>
> If we had a convention for how to name internal helper methods, which
> would make it clear that they are methods of the current object and not
> free functions (a bit like `m_` does for data members), we could omit
> `this` when calling such a method. But we don't have that at the
> moment.
>

Hi,

I think I tend to use both ('this->' and 'm_' prefix) because the 'm_'
prefix is used and I have some python habit of using 'self'.

I am absolutely fine with your approach to use exactly one of those two
markers since both says that they are referring to a member of the
class, and having both is redundant. Also, having a rule is a good
thing, so count me in.

Extending the same sort of convention to helper methods is also
reasonable. I do not have an opinion on what should be the prefix.
However, classes and structs will more likely have both public (without
prefix) and protected/private (with prefix) methods, which can lead to a
somewhat less uniform style when writing methods body. I tend to think
that for this reason just using 'this->' all the time might be easier,
but this is not a strong opinion, I am fine using a prefix. On the
other hand, having a prefix can be a nice hint when refactoring code
that a given method is not part of the public API and therefore easier
to change.

Lancelot.