10

I was searching everywhere, but I probably used the wrong terms. I haven't found an option for this.

The only thing I found is this unanswered question (which is however a bit broader): CPP lint: Can you enforce use of this for class variables? .

P.W
  • 26,289
  • 6
  • 39
  • 76
Martin Pecka
  • 2,953
  • 1
  • 31
  • 40
  • Why do you want that? – Michael Chourdakis May 09 '19 at 11:07
  • 1
    Always good to use approach like mentioned the link you have shared. One way I differentiate member variable vs local variable is Eg: 'm_sum' for member variable and just 'sum' for local variable. If you are trying to enforce this to overcome some code analyser tool notifications, you could probably make it a false positive. Not a suggested practice to use 'this->' in front of all member variables. – Shrikanth N May 09 '19 at 11:11
  • 1
    I upvoted this because this is a clear question which shows effort, but I really struggle to agree with the idea ... – L. F. May 09 '19 at 11:19
  • Code formatting is ultimately a topic of personal preference. There are ways to format that gather a certain consensus, but this is about how to do a specific formatting, not if it's good or bad. I also believe consistent formatting is better than """better""" but inconsistent one. – JBL May 09 '19 at 11:26
  • I'm working on a project where this is one of the requirements in the code style. No reason to discuss. It just has to be that way. – Martin Pecka May 09 '19 at 11:59
  • I wish it had that ability, but the opposite -- enforce disallowing using "this->". – Eljay May 09 '19 at 14:29
  • 1
    I created LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=41824 for this issue. – Martin Pecka May 10 '19 at 07:52
  • 1
    There's https://oleksandrkvl.github.io/2020/10/16/enforce-this-style-check.html – user541686 Jul 24 '22 at 02:51
  • 1
    @user541686 thanks! The LLVM bug was [moved to github](https://github.com/llvm/llvm-project/issues/41169), and I've posted info about this implementation to the bug. – Martin Pecka Jul 24 '22 at 17:59

2 Answers2

5

Given the existing options, I dont believe this is possible with clang-format, not that it will be in the future. The main reason for this is the way the program works. It doesn't parse the C++ code into and AST, instead it tokenizes the text without the need for includes (defining what it a member and what is a global variable) not a compile database (influencing defines, include paths ...) It's even possible to give it a piece of code and reformat that.

From the nature of the problem, one could expect, If it can exist within the clang-tooling, to be a compiler warning or clang-tidy. As this should be cheap to check at compile time, a warning could be possible, although, warnings are usually about globally accepted improvements. I don't believe there a consensus on that.

So, that leaves clang-tidy. Looking at the options, I don't see the option. I see it being possible as a readability-* check, as more controversial checks are allowed in here. Though, I think if you want this, you should write it yourself and provide it to the project.

A final personal note: I am not convinced that this-> is a good solution, though nor is starting everything with m_ (already possible), or not doing it. It would be nice if the check would be configurable to add/remove this->, so one could try things out.

ToddR
  • 300
  • 1
  • 11
JVApen
  • 11,008
  • 5
  • 31
  • 67
4

From the look of clang-format's documentation on its style options, this doesn't seem possible.

JBL
  • 12,588
  • 4
  • 53
  • 84