We (committers at least, with contributors would even be better) could decide
to use the same formatter.
This would helps when merging from custom projects or backporting to them...
I tried this once by sharing my Eclipse formatter at
https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766027
So we could decide on our own rules and get more legible and consistent
formatting
Now that more people use InteliJ we could start from an Eclipse formatter
https://blog.jetbrains.com/idea/2014/01/intellij-idea-13-importing-code-formatter-settings-from-eclipse/
https://plugins.jetbrains.com/plugin/6546-eclipse-code-formatter
It seems there is no other way around
https://stackoverflow.com/questions/29226589/export-intellij-idea-code-formatting-rules-to-eclipse
Maybe ultimately using CheckStyle as suggested? I remember being rebuffed a
decade abo when I suggested to use Findbugs...
I'm not strongly opinionated about that, but when I think about external
mergings...
Jacques
Le 29/10/2017 à 10:53, Michael Brohl a écrit :
I think this is just a formatting change becaused I used our formatter for
Eclipse.
Not really something worth a discussion, is it?
Am 29.10.17 um 10:07 schrieb Jacques Le Roux:
Le 28/10/2017 à 16:45, mbr...@apache.org a écrit :
- for (int i = 0; i < modelField.length; i++)
- sb.append(PAD_CHAR);
- data = sb.toString();
- }
+ for (int i = 0; i < modelField.length; i++)
+ sb.append(PAD_CHAR);
+ data = sb.toString();
+ }
Hi All,
I find this ambiguous. We have few options here:
1)
for (int i = 0; i < modelField.length; i++)
sb.append(PAD_CHAR);
data = sb.toString();
2)
for (int i = 0; i < modelField.length; i++) {
sb.append(PAD_CHAR);
}
data = sb.toString();
3)
for (int i = 0; i < modelField.length; i++) sb.append(PAD_CHAR);
data = sb.toString();
4)
for (int i = 0; i < modelField.length; i++) sb.append(PAD_CHAR);
data = sb.toString();
Which one do you prefer? Of course this should be a general rule, not only for
this case!
Thanks
Jacques
