You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Michael Vorburger (Jira)" <ji...@apache.org> on 2020/06/14 16:33:00 UTC

[jira] [Resolved] (FINERACT-1006) Auto Format Source Code

     [ https://issues.apache.org/jira/browse/FINERACT-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Vorburger resolved FINERACT-1006.
-----------------------------------------
    Resolution: Fixed

> 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)