Skip to content
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

Add source code formatting? #33

Open
mikavilpas opened this issue Mar 30, 2023 · 6 comments
Open

Add source code formatting? #33

mikavilpas opened this issue Mar 30, 2023 · 6 comments

Comments

@mikavilpas
Copy link
Contributor

This issue is to open a discussion on whether the project should have a source code formatter taken into use.

Why use a formatter?

What benefits could it bring?

  • all code would look exactly the same so it's easier to reason about
  • coding becomes easier as developers don't have to pay any attention to formatting

What does it do exactly?

A formatter typically has the following functions:

  • it integrates into the IDE and automatically formats the current file when it is saved
  • it integrates to pull requests and fails the CI build in case the PR's code is not correctly formatted

Thus adding a formatter would need the following:

  • every developer must install an IDE plugin OR they have to run an extra formatting command before submitting their PR
  • a CI build needs to be created

My suggestion

I have previously worked with a java formatter called google-java-format which has good plugins for IDEA, Android Studio (I have no personal experience using it with Android Studio) and I think one developer used it with Eclipse. The formatting style in this formatter is not configurable at all, you can literally change nothing, I think. This means it's extremely opinionated but also very easy to set up.

@Aquafina-water-bottle
Copy link
Contributor

I'm in full support for having a code formatter.

Android Studio has a code formatter built in already (right click com.kamwithk.ankiconnectandroid in the tree file explorer -> Reformat Code). This one in particular is configurable, and we can export the settings so everyone can reformat the code to the same style.

I'm thinking in a future PR, we can just export the settings, add instructions on how to use it to the contributing section, and require that people use it before any PR. Similarly, I'm thinking of changing all the snake_case variables to camelCase, but these changes will only be done after the current PRs are merged.

@Twinov
Copy link
Contributor

Twinov commented Apr 1, 2023

Thought it was odd to use snake_case in a Java project but went with it because I saw it in the rest of the code :p
Also support adding a formatter.

@KamWithK
Copy link
Owner

KamWithK commented Apr 5, 2023

I think this is a good idea overall
If we do so though I would want to ideally just use the default one within Android Studio unless there's a good reason to use a third party one?

@mikavilpas
Copy link
Contributor Author

I think the Android Studio one is perfectly fine. It will most likely work well in this project.

Since you asked, I'll try to give a comparison. I think the main differences are:

  • the google one is checked by CI, others have to be checked manually (or just not checked at all)
  • the google one cannot be configured. But I think this is not a big deal in the end as long as the Android Studio one can be committed and will be taken into use automatically

Overall, I don't think these are big or even compelling reasons. 👍🏻

@KamWithK
Copy link
Owner

KamWithK commented Apr 7, 2023

I think the Android Studio one is perfectly fine. It will most likely work well in this project.

Yeah it's probably fine

* the google one is checked by CI, others have to be checked manually (or just not checked at all)

This would be cool but we don't really have any other CI stuff at the moment so likely would not be worth it right now I feel

@KamWithK
Copy link
Owner

KamWithK commented Apr 7, 2023

If someone is up to creating a PR for this then it'd be a welcome change
I'm personally not a big Java user so a lot of my code formatting would likely cross between Java, Python and JavaScript naming and styling conventions currently
Using a linter and formatter would probably help to refactor out and in the future avoid these mistakes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants