[
https://issues.apache.org/jira/browse/FINERACT-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17128819#comment-17128819
]
Petri Tuomola commented on FINERACT-1006:
-----------------------------------------
I'm fully with [~vorburger] on the 4 vs 2 spaces for a tab argument! When I
started contributing to Fineract, I checked the Google style guide and the 2
spaces thing stood out like a sore thumb. I was then happy (but surprised) to
see that actually almost all of the Fineract code doesn't actually follow that
stated guideline :)
But it would be great to have a tool to both a) ensure everything in the
repository so far is consistently formatted and b) check / fix formatting of
anything being added / updated...
> Auto Format Source Code
> -----------------------
>
> Key: FINERACT-1006
> URL: https://issues.apache.org/jira/browse/FINERACT-1006
> Project: Apache Fineract
> Issue Type: New Feature
> Reporter: Michael Vorburger
> Assignee: Manthan Surkar
> Priority: Major
> Fix For: 1.4.0
>
>
> In https://github.com/apache/fineract/pull/933 for FINERACT-821, [~Manthan]
> exploring using an "Auto Source Code Formatter Tool", and I'm creating this
> issue to further explore and discuss that...
> Manthan originally used https://github.com/google/google-java-format, which
> seems nice at first, but when I noticed how it's hard-coded to 2 instead of 4
> space indentions, I really struggled... I respect that this can seem "silly"
> (and I agree that on such matters the most important thing is for a project
> to just pick 1 code formatting convention and then stick to it), but 2 spaces
> is a very JS/Go rule, and not used in any (open source) Java community that I
> know of. I personally feel reasonably strongly against adopting a convention
> (2 spaces) that makes all Fineract code looks different than e.g. JDK's own
> or Spring's etc. etc. code. Interestingly, even (Google's!) Android AOSP uses
> 4 not 2 space indention, see
> https://source.android.com/setup/contribute/code-style, and thus does not
> follow
> https://google.github.io/styleguide/javaguide.html#s4.2-block-indentation ...
> ;=)
> Long story short: I'm actually *FOR* further exploring auto formatting for
> this project, but if we really do do this, then how about not as a manual
> "one off", but through integrating Gradle task that any future contributor
> can easily use? But I'm *AGAINST* us using google-java-format as-is... :P
> Doing a little bit more research on this topic seems justified. Here are some
> pointers:
> * https://plugins.gradle.org/search?term=format
> * https://plugins.gradle.org/search?term=formatter
> * https://plugins.gradle.org/search?term=code+style
> *
> https://medium.com/@alexprut/integrate-google-java-style-guide-in-a-java-project-567abb6d7987
> *
> https://medium.com/@aruny3/improve-code-formatting-on-every-commit-7fbb0cdfdab6
> I have not looked more closely at all of these (but perhaps [~Manthan] you
> would be interested to do a quick comparison?), but from a quick glance,
> doesn't https://github.com/diffplug/spotless look pretty neat? It,
> apparently, supports several formatter plugins... one of them being
> google-java-format (which I really don't look, because of the 2 spaces), but
> what looking into making that use our existing
> https://github.com/apache/fineract/blob/develop/config/fineractdev-eclipse-preferences.epf,
> which I created and which should match
> https://github.com/apache/fineract/blob/develop/fineract-provider/config/checkstyle/checkstyle.xml
> ... that would be cool, but we would get 100% consistent auto-formatting in
> an IDE AND have the equivalent on the CLI through Gradle - that's the holy
> grail! ;-)
> [~awasum] [~ptuomola] your input here obviously very welcome (and anyone
> else's)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
