Apply some kind of code formatting in the master branch

[douglasrizzo]

In PR #54 we talked about formatting the code base according to some kind of standard. Back then, these remarks came up:

reformatted codebase using Google Style Guide (with 4 spaces, not 2) <-- this is ok, but working at Google myself there is one think I dislike about the style we use at Google, which is the 80 character limit in code lines. As long as that constrainted was not enforced, this is fine! (hard to see in the diff online :)

added EditorConfig file to enforce code standard <-- same with this one. Code standards are very personal things. I need some time to see if I can live with this standard

I understand this would be a welcome change in the repo, but I would like to discuss a few things before working on this.

Instead of depending on a specific IDE to format code, I propose using an IDE-independent tool, such as uncrustify. We configure a formatting style in a .cfg file, let people work in the IDE they like the most and, right before pushing to the repo (or to the master branch), use uncrustify to format all files. I've employed similar editor-independent tools, like YAPF or black, in my Python projects with great success.

I think this would be a nice addition to the repo since, regardless of code standard, I've been finding files with multiple blank lines, no spaces around operators or too many spaces and other issues which could be automatically fixed by a tool. If we do this right, we can even create a CONTRIBUTING.md file in the repo, teaching people how to comply to the standard before making a pull request.

I can come up with a style that would be welcome in the repo (large character limit for lines, indentation with 4 spaces), add the .cfg file to the repo and, after that, we can periodically format the code base using uncrustify, keeping everything according to a standard.

People can still use whatever code standard they want while working on their computers, as long as they uncrustify all Java files just before contributing to the repository.

As for viewing the files online, on GitHub. There is a way to configure the online viewer by adding a .editorconfig file in the repo. It only has 6 or 7 options, but not only does it configure some major options for the online viewer, it also helps to configure most code editors (natively or via plugins) so that gross mistakes are not made in the code (enforce LF instead of CRLF at the end of line, use spaces and not tabs as indentation, use UTF-8 encoding on files etc.).

[santiontanon]

That sounds good to me! Again, as long as the project does not end up depending on these services, like "uncrustify", this is all ok. For example, a way would be to describe the code format, and "suggest" that contributions are passed through uncrustify before submitting in the CONTRIBUTING file. But I would not want to "require" it, just suggest it, just in case uncrustify happens to all of a sudden die or something :)