fix clang-tidy errors in hyprland module

[zjeffer]

CC: @Syndelis @khaneliman because you guys seem to be the most recently active in these files

[alebastr]

member_ comes from Google code style recommended in the project README. The style isn't being followed strictly (esp. in regards to enum/constant names), but at least that part was consistent. Well, mostly.

Maybe modifying .clang-tidy to follow the project style would be better?

[zjeffer]

I personally really dislike the trailing underscore style to mark member variables (which is why I initially set it to use the m_ style here). I don't think it's very clear at all which variables are member variables and which aren't when you just use a trailing underscore. That style also often gets used for temporary variables in the code, so we're mixing styles (I think there's a couple ocurrences of this mixing happening in the code I changed in this PR).

I'm obviously not the one to choose this, @Alexays what do you think?

[alebastr]

I don't even mind the m_ style as long as it is consistent across the codebase. I.e. someone does the complete conversion and adds .git-blame-ignore-revs.
Obviously, that would require manual merge and update for most of the pending PRs. That's the unavoidable price of consistency.

Currently, ~10 files of 200 are using the m_ prefix style. Any change to the rest of the sources would make clang-tidy CI job fail, effectively rendering it useless. And all these Invalid case style for... editor warnings don't add to my happiness.

That style also often gets used for temporary variables in the code, so we're mixing styles

That's fair. And I might even introduced some of those, just like inconsistent case for constants and enums. But fixing and enforcing style for that would be less disruptive.

[zjeffer]

I.e. someone does the complete conversion and adds .git-blame-ignore-revs.

I would even volunteer to do this by myself for every single file in the repo, that's how much I hate the trailing underscore style ;)

That .git-blame-ignore-revs file is really interesting, I didn't know this feature existed.

[Alexays]

I don't mind either between m_ or _, I'd be more in favor of going back to the suffix to follow the readme guidelines and avoid too many conflicts over current PRs.
And it will surely be easier this way to get the green check on the clang-tidy side.

[zjeffer]

And it will surely be easier this way to get the green check on the clang-tidy side.

This shouldn't really be an issue because the clang-tidy action only looks at the files changed in the PR, not all files.

But I understand that current PRs would have lots of annoying conflicts. I'll look into changing the clang-tidy rule and making the necessary changes in the hyprland module.