Use autoformatters to enforce style of all programming languages in cosmos.

[arnavb]

This is a(n):

• [ ] New algorithm
• [ ] Update to an existing algorithm
• [ ] Error
• [x] Proposal to the Repository

Details:

Currently, our repository contains various style guides in guides/coding_style. Enforcing that contributors follow this style guide is very difficult for contributors and maintainers alike. As such, I propose that we add autoformatters for all programming languages being used in cosmos and enforce their usage through Travis CI. This way, fixing code style is a simple matter of running one command. In addition, I believe that formatters that don't allow configuration are better, so that there are no arguments over what style is better; you simply follow whatever the autoformatter does.

I will use this as a tracking issue for all the autoformatters available. I will probably add some of them, but others can also do so (while referencing this issue).

Autoformatters:

• [ ] C++ - clang-format with Google C++ Style Guide
• [x] Python - Black, the uncompromising Python code formatter. (PR: #3949)
• [ ] Java - google-java-format is a Java formatter that does not allow configurability.
• [ ] C - clang-format (with what style guide?)
• [x] Javascript - Prettier, an opinionated code formatter. (PR: #3950)
• [ ] Ruby - Rubocop, which formats based on the community style guide and in addition finds linting errors.
• [ ] C# - Not sure if anything can be done about C#, considering that this is Travis CI, although Travis does support Windows.
• [ ] Go - Gofmt without a doubt.
• [ ] Rust - Rustfmt without a doubt.
• TODO: Add more programming languages.

If anyone would like to discuss more code formatters or other options, please feel free to reply to this issue. If anyone wants to add one in particular to Travis CI, then reference this issue and go for it!

[yedhink]

@arnavb I think this is a must needed enhancement. For C and C++ I can guarantee that clang-format works great. It has direct plugins available for text editors, which makes formatting on save/on the go easier.

We can make use of a clang-format configuration file for applying sane defaults for users. The file can be directly referenced using -style=file option or by specifying the location in the editor settings.

Code Styles

My suggestion would be to go with the google style guide. Available for multiple languages, and most importantly has tools which could enforce the same while coding.

Known Plugins

Vim : https://github.com/rhysd/vim-clang-format Emacs : https://melpa.org/#/clang-format Vscode : https://marketplace.visualstudio.com/items?itemName=xaver.clang-format Sublime: https://packagecontrol.io/packages/Clang%20Format

[arnavb]

@yedhink Cool! Would you be willing to add configuration for this to Travis CI? Make sure to reference this issue when doing so.

[arnavb]

@yedhink Also, what style do you propose we use for pure C?

[yedhink]

@arnavb Yes. I would love to add the configurations. Is there someplace I can message you directly, so as to clear doubts on the same?

Like i had mentioned, going with the google style guide can work well for c++. But for pure C, i would strongly recommend following the Gnome style guide for pure c. Pure c, does have many accepted style guides like the Linux Kernel Style, GNU Style etc. The gnome style guide tries to bring about a comparative form of style guide, where the user can choose from the given best choices.

For example: Linux Kernel Style : Tabs with a length of 8 characters GNU style : Each new level is indented by 2 spaces My Suggestion : We should definitely stick onto two spaces, since tabs can vary depending on env. 8 char tabs can make the code not fit in a 80 width terminal. Also i use vertical splits while working, the 2 spaces indentation can play nicely while doing so.

To nurture out a proper c-style guide, we can choose the best choices from the gnome style guide and make clang format follow the same.

[arnavb]

@yedhink I don't think that's a great idea, because the GNU style also comes with an unusual brace pattern. In my opinion, 2 spaces is too less for a language like C as well. I think sticking with the kernel style guide, except with 4 spaces, is best. The reason they use 8 char tabs is to discourage people from indenting more than 3 levels. However, since this is a repository for algorithms, such a situation is unavoidable.

You can always contact me by email (visible on my profile page).

[yedhink]

@arnavb Sure. We can manage that. I would love to make a PR for the same. But currently it seems that the Build is failing. Should i work on that first and then move to this? or is someone already working on the build?

[yedhink]

@arnavb I have made a PR (#3957) for fixing the current build failure. See if it's okay to be merged.