Clarify Coding Style Guidelines (?)
I'm very interested in contributing to this project if I have the time, and in fact I've already made my first (tiny) pull request! However, code style is one thing I'm hesitant about: the readme specifically requests it be followed, but never specifies what that actually entails.
If you have any specific aspects of code style that should be followed, that aren't entirely obvious (such as tab width), I'd recommend you write those down somewhere in another readme file. Normally I would just trust my IDE (Android Studio) to have reasonable formatting defaults, but different people may use different IDEs (I hear this is rare for Android development, but it can't be ruled out) and the defaults may be different there; so specifying which (IDE's) set of standards should be used would help too.
If "coding style" refers to broader paradigms like Dependency Injection or sth, it's possible that those can't easily be written out into a readme doc; but it could be useful to still create one as a baseline for an evolving document, as clear patterns emerge and can be added post-hoc.
Of course if you have no preferences for details like that, it's also fine to just ignore this. I was just surprised that I couldn't find a styleguide anywhere, given that the readme explicitly mentions the concept.
I'm sorry for the confusion. What I meant by code style is mainly the structure of the code. For instance, I put all file operations (such as copy, compress, etc.) in tasks, so if you'd make a new feature that deals with files, it must be in tasks. A recent contribution, for example, was made of a feature that allows merging APKs files, but didn't make task for that (which clearly should). I did end up accepting it just because I was planning to make changes to the tasks anyways.
Other than that, I don't really have any formatting preferences over the default Android Studio code style (which I'm sure the majority do follow it anyway).
I've never encountered a contribution with different code format, so it's good to know that it might be a possibility, and yes it should be addressed in the README.
I put all file operations (such as copy, compress, etc.) in tasks, so if you'd make a new feature that deals with files, it must be in tasks.
Oh, I didn't know about that, will keep in mind next time :)
I didn't know about that
That's on me, as there were no clear instructions provided.
The problem is that I don't follow a certain architecture in my code, so it would be difficult to make a thorough guideline for contributors to follow. However, I think going through the code related to a feature one wants to implement, would give a good idea on how the code is structured.
Anyway though, I'll try to make a general guideline hopefully soon.