Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should the setting of IndentPPDirectives be? #6316

Closed
skullydazed opened this issue Jul 12, 2019 · 17 comments
Closed

What should the setting of IndentPPDirectives be? #6316

skullydazed opened this issue Jul 12, 2019 · 17 comments
Assignees
Labels
breaking_change Changes that need to wait for a version increment core discussion help wanted

Comments

@skullydazed
Copy link
Member

Pre-processor formatting

Currently our preprocessor directives don't follow a consistent style. Sometimes the indent level matches the code's indent level, sometimes no intenting is used at all, and sometimes PPD's are indented to their own indent level.

Since we are switching to clang-format we have to choose one of the 2 pre-defined options, neither of which are a good fit for all the ways PPD's are used in QMK. We are looking for feedback from people who work on core code to make this decision.

Possible PPDIS values:

None

PPDIS_None (in configuration: None) Does not indent any directives. You can see this in the future_ppdis_none branch.

#if FOO
#if BAR
#include <foo>
#endif
#endif

After Hash

PPDIS_AfterHash (in configuration: AfterHash) Indents directives after the hash. You can see this in the future branch.

#if FOO
#  if BAR
#    include <foo>
#  endif
#endif

Before Hash (Later, after clang-format 9.0.0 propagates)

PPDIS_BeforeHash (in configuration: BeforeHash) Indents directives before the hash. This option is only available in clang-format 9.0.0 and later. The latest version shipped by homebrew (and perhaps other systems) is 8.0.0.

#if FOO
  #if BAR
    #include <foo>
  #endif
#endif
@skullydazed skullydazed pinned this issue Jul 12, 2019
@skullydazed skullydazed self-assigned this Jul 12, 2019
@skullydazed skullydazed added breaking_change Changes that need to wait for a version increment core discussion help wanted labels Jul 12, 2019
@drashna
Copy link
Member

drashna commented Jul 12, 2019

Personally, I don't have a preference one way or the other. I just want consistency :)

@XScorpion2
Copy link
Contributor

I lean towards None or Before Hash. After Hash is confusting to look at if you don't have a good c syntax highlighting.

@XScorpion2
Copy link
Contributor

For none, I do usually expect a comment on the #endif line stating which #if it was for:
#endif // BAR

@drashna
Copy link
Member

drashna commented Jul 12, 2019

For none, I do usually expect a comment on the #endif line stating which #if it was for:
#endif // BAR

100% this.

@noroadsleft
Copy link
Member

I have a slight preference for BeforeHash above AfterHash. None is a complete non-starter for me unless the #endif has a comment indicating which directive is terminating, as @XScorpion2 said.

@zvecr
Copy link
Member

zvecr commented Jul 13, 2019

Just incase anyone wants a more real world example of BeforeHash https://github.com/zvecr/qmk_firmware/tree/future_unformatted_before

My order of preference would be BeforeHash then None and then way down AfterHash

@vomindoraan
Copy link
Contributor

vomindoraan commented Jul 13, 2019

I really don't like AfterHash for the simple reason that, other than looking odd, it makes code harder to grep for. I'm used to adding \s* after every # in my regexes, but it'd be great if I didn't have to do this, and not everyone will remember to do it anyway.
None is a bit better, but not ideal either, as it can make complex preprocessor logic (which there's a lot of in QMK, due to feature flagging etc.) hard to understand and parse visually.
BeforeHash is the only viable option for the long term, imo. As an added benefit, it makes the #endif comments unnecessary, which is good since those may be hard to enforce anyway.

Another thing worth discussing is whether preprocessor directive indentation should affect the indentation of regular code. In my opinion the answer is no, and I believe clang-format will format code like this by default. Here are some examples of how preprocessor indentation can affect the readability of code.

@vomindoraan
Copy link
Contributor

vomindoraan commented Jul 13, 2019

In summary, I think we should go with BeforeHash + preprocessor directives having their own, separate indentation levels in most cases. The exception is when following regular indentation clearly makes a piece of code more readable (readability over consistency). However, I'm not sure if it's possible to set up clang-format to allow for this (and it might be worthwhile to stay totally consistent, anyway).

@fauxpark
Copy link
Member

Agree with @vomindoraan - BeforeHash with separate indentation as much as possible. But until that option is more widespread perhaps AfterHash is best so there is at least some form of indentation.

@vomindoraan
Copy link
Contributor

vomindoraan commented Jul 13, 2019

I believe BeforeHash is currently the most widespread option in the repo in general. As far as core code is concerned, we could always reformat all of it in this round of breaking changes.

@nooges
Copy link
Member

nooges commented Jul 13, 2019

My preference is None, but I’m okay with BeforeHash

@nooges
Copy link
Member

nooges commented Jul 13, 2019

@vomindoraan I’m with you on that preprocessir directives should not affect the indentation of regular code.

@yiancar
Copy link
Contributor

yiancar commented Jul 13, 2019

I am for BeforeHash as well. Some people like to add a comment at the endif in those cases as well, I dont mind that TBH

@skullydazed
Copy link
Member Author

It's clear that long term BeforeHash is the preferred setting. We will need to monitor clang-format's propagation to determine when we can use that.

In the meantime it seems like we can choose AfterHash or None. If we choose None clang-format is not able to enforce #end comments. Given that, which setting makes sense until we can use BeforeHash?

@vomindoraan
Copy link
Contributor

My vote goes to AfterHash until Clang 9 is more widely available. I think having at least some indentation is better than having none, since we can't enforce the ending comments. We'll just have to get used to taking the spaces into account when searching through code for the time being.

@ishtob
Copy link
Contributor

ishtob commented Jul 16, 2019

also vote BeforeHash

@skullydazed
Copy link
Member Author

Thanks for your comments everyone. For now we will use AfterHash, and we will revisit switching to BeforeHash at each breaking change window until clang-format 9 has enough adoption.

@skullydazed skullydazed unpinned this issue Aug 2, 2019
manna-harbour added a commit to manna-harbour/qmk_firmware that referenced this issue Apr 6, 2020
noroadsleft pushed a commit that referenced this issue Apr 9, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per #6316
violet-fish pushed a commit to violet-fish/qmk_firmware that referenced this issue Apr 12, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
Quarren42 pushed a commit to Quarren42/qmk_firmware that referenced this issue Apr 15, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
kylekuj pushed a commit to kylekuj/qmk_firmware that referenced this issue Apr 21, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
bitherder pushed a commit to bitherder/qmk_firmware that referenced this issue May 15, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
drashna pushed a commit to zsa/qmk_firmware that referenced this issue May 24, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
sowbug pushed a commit to sowbug/qmk_firmware that referenced this issue May 24, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
fdidron pushed a commit to zsa/qmk_firmware that referenced this issue Jun 12, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
turky pushed a commit to turky/qmk_firmware that referenced this issue Jun 13, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
jakobaa pushed a commit to jakobaa/qmk_firmware that referenced this issue Jul 7, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
thorstenweber83 pushed a commit to thorstenweber83/qmk_firmware that referenced this issue Sep 2, 2020
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
BorisTestov pushed a commit to BorisTestov/qmk_firmware that referenced this issue May 23, 2024
* Add PS2_MOUSE_ROTATE to compensate for device orientation

* fixup! Add PS2_MOUSE_ROTATE to compensate for device orientation

* Reformat with IndentPPDirectives: AfterHash as per qmk#6316
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking_change Changes that need to wait for a version increment core discussion help wanted
Projects
None yet
Development

No branches or pull requests

10 participants