-
Notifications
You must be signed in to change notification settings - Fork 23
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
style: add clang format #81
Conversation
Failing as coveralls is annoyingly going up and down with every change |
@jimsch please review this |
I’d like to contribute some code, though it would make sense to format the code first |
As you said style is subjective. I can live with most things but there are a couple of things that would drive me crazy:
In short I did a lot of my learning of style with K&R. |
Part of the reason you are going to have a drop in coverage is that a large number of error cases don't have testing on them. This means that chaning
|
Sure, i’m 100% agnostic to the style. |
41cc568
to
dbff840
Compare
lets wait for #82 to land, otherwise we get tons of conflicts... |
29609e6
to
1bbfadd
Compare
I have the feeling that spaces are the way to go with clang-format, when using tabs, the code looks pretty special (e.g. macros, function arguments etc.)... It offers the option to costumize the width if using spaces, so not discussions needed here... If you really want tabs, I'd suggest that you remove this last commit and play with the clang-format file as well as with the reference here: https://clang.llvm.org/docs/ClangFormatStyleOptions.html |
I can live with most of this, however some of it I really don't like.
It is just too easy to add a second statement in the if statement w/o adding the braces. Is there a way to force doing braces in this case? |
we are currently using chromium based style in general, this is based again on google style: |
I'm not sure, if clang-format will be able to insert brakets to existing code, clang-format is mostly doing indentation, though we think exactly the same, and therefore we are using clang-tidy which reports on bad style: https://clang.llvm.org/extra/clang-tidy/checks/readability-braces-around-statements.html this could be added in a next MR |
this can be seen by running |
How soon do you think this is going to be ready to pull in. I am waiting on some stuff that I want to do for it. |
This can be done at any time, i can rebase today and let you review again? |
sounds good |
458e49f
to
9b5349b
Compare
just realized that it would be very good to merge #93 first, as otherwise we get conflicts with |
travis failing due to a timeout, nothing about this patch |
depends on #79