-
Notifications
You must be signed in to change notification settings - Fork 407
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
ClangFormat Style #2157
Comments
I really dislike |
I know David, but I like it and as long as not a healthy majority of the team agrees with you I win :-P |
Yeah, of course. Like I said, I can’t come up with a particularly good reason why I don’t like it. I was just logging a data point. |
--- old 2019-05-28 17:25:36.000000000 -0400
+++ new 2019-05-28 17:25:53.000000000 -0400
@@ -1,98 +1,79 @@
-#define A_MACRO \
- int a; \
-int bbbbb ;\
-double dddddddddddddd; \
-int e;
+#define A_MACRO \
+ int a; \
+ int bbbbb; \
+ double dddddddddddddd; \
+ int e;
-namespace ANameSpace
-{
+namespace ANameSpace {
namespace BNameSpace {
-template<class FoolMe, class B,
- class C>
+template <class FoolMe, class B, class C>
struct Foo {
- Foo() {};
+ Foo(){};
int a;
- double b,c;
- const double e=5.0;
+ double b, c;
+ const double e = 5.0;
const int an_int = 5;
void foo() {}
int bar_me() { return 0; }
- double tree (int a, int b,
- int call_me_later = 0,
- double me_too1 = 1.0,
- double me_too2 = 1.0,
- double me_too3 = 1.0,
- double me_too4 = 1.0,
- double me_too5 = 1.0,
- double me_too = 1.0) {
+ double tree(int a, int b, int call_me_later = 0, double me_too1 = 1.0,
+ double me_too2 = 1.0, double me_too3 = 1.0, double me_too4 = 1.0,
+ double me_too5 = 1.0, double me_too = 1.0) {
return 1.0;
}
- double tree_with_very_very_very_very_long_function_name (int a, int b,
- int call_me_later = 0,
- double me_too1 = 1.0,
- double me_too2 = 1.0,
- double me_too3 = 1.0,
- double me_too4 = 1.0,
- double me_too5 = 1.0,
- double me_too = 1.0) {
+ double tree_with_very_very_very_very_long_function_name(
+ int a, int b, int call_me_later = 0, double me_too1 = 1.0,
+ double me_too2 = 1.0, double me_too3 = 1.0, double me_too4 = 1.0,
+ double me_too5 = 1.0, double me_too = 1.0) {
switch (call_me_later) {
- case 1:
- return 1.0;
- break;
+ case 1: return 1.0; break;
case 2: return 2.0; break;
case 3:
me_too *= me_too1;
me_too *= me_too2;
me_too *= me_too3;
me_too *= me_too4;
- break;}
+ break;
+ }
}
- if(me_too < 0)
+ if (me_too < 0)
return 0;
else {
me_too += me_too1;
me_too += me_too2;
- return me_too;
+ return me_too;
}
- void
- break_after_return_type(int a) {
- if(a==0) {
- printf("Huch\n");}
-else {
+ void break_after_return_type(int a) {
+ if (a == 0) {
+ printf("Huch\n");
+ } else {
printf("OhNo\n");
}
}
};
-void mean (int a,
- int b = 0, double gamma = 0.0,
- int64_t delta = 0 ) {
- b = 1;
+void mean(int a, int b = 0, double gamma = 0.0, int64_t delta = 0) {
+ b = 1;
gamma = 5;
- delta = 1; b = 2;
-
+ delta = 1;
+ b = 2;
- Foo<int, double,double > f;
+ Foo<int, double, double> f;
f.foo();
- f.tree(a, b,delta);
+ f.tree(a, b, delta);
-
- b = 5 + // First thing
- 3;// Second Thing
+ b = 5 + // First thing
+ 3; // Second Thing
}
-}}
+} // namespace BNameSpace
+} // namespace ANameSpace
-void args (int a)
-{
- printf("Too\n");
-}
+void args(int a) { printf("Too\n"); }
-void args (int a)
-{
+void args(int a) {
printf("Too\n");
printf("Too1\n");
printf("Too2\n");
@@ -100,12 +81,12 @@
printf("Too4\n");
}
-int for_loop (int a) {
- int sum= 0;
- for(int i=0; i<a; i++) {
- sum+=i*a;
+int for_loop(int a) {
+ int sum = 0;
+ for (int i = 0; i < a; i++) {
+ sum += i * a;
}
- for(int i=0; i<a; i++) sum+=1;
+ for (int i = 0; i < a; i++) sum += 1;
return sum;
} |
For the sake (unnecessary) thoroughness, my main reason for disliking int i = 0;
double val = 0.0;
Kokkos::View<double**, typename ExecutionSpace::memory_space, Kokkos::LayoutRight> data = { }; which is pretty unreadable. If we can get better about always using The other problem is that, even with auto value = /*...*/;
auto factor = /*...*/;
auto some_complicated_variable_that_needs_explanation = /*...*/; The spacing makes it feel like the person with the descriptive variable name is doing something wrong, when in fact it may be necessary to increase the readability of the program. Again, though, I really don't care that much. I just wanted to log a data point. Any use of a formatting standard is so much better than what we have that I'm all for it. (Also, we should make sure that automatic formatting is escapable. There is quite a bit of research to show that there are times when developers need to use spacing outside of a prescribed format to convey something to the reader of the code. I believe |
This can done using |
Also it looks like there are ways how you can apply clang-format only to the changed lines. People have done scripts (i.e. github hooks) for that. |
I just ran the thing over the whole code base: 111k lines added, 106k lines removed out of 264k lines. This is what I did:
Based on a sample of the diff the changes are mostly very minor: - offset_type get_bin_offsets() const { return bin_offsets;}
+ offset_type get_bin_offsets() const { return bin_offsets; } - void operator() (const bin_binning_tag& tag, const int& i) const {
- const int j = range_begin + i ;
- const int bin = bin_op.bin(keys,j);
+ void operator()(const bin_binning_tag& tag, const int& i) const {
+ const int j = range_begin + i;
+ const int bin = bin_op.bin(keys, j); A lot of it is indentation for namespace: i.e. we often have code indented 2 spaces for almost everything. I.e. inside a |
This is going to be a nightmare for any outstanding branches; basically all changes in those branches will just be lost, I think. We need to be absolutely sure we want this and don’t want things on outstanding on branches before we make this change in develop
|
New files will be ok but otherwise conflicts will be problematic. We will discuss this in todays meeting. |
You just need someone volunteering to update all the pull requests. As long as you are continuously fixing formatting from newest to oldest commits, you should be fine. |
You will need to specify the exact clang-format version(s) that are supported. |
No reordering of headers: needs to be explicitly turned off. |
This is now merged including the automated testing of compliance for pull requests. |
@dalg24 and @Rombur requested that we add a clang-format style. The following is what I like and what is as far as I can tell the closest to the style we have been employing manually:
The
AllowShortLambdasOnASingleLine
is a pretty recent clang only, so I commented that out for now. This is an example test code:Formatted:
If anyone has any gripes about this let me know. The plan would be to apply this after the 2.9 release. The 3.0 release is not supposed to have any code changes, but just the build system overhaul, so it is a good target to do a wholesale reformatting.
The text was updated successfully, but these errors were encountered: