Consistent Code Formatting of Source Code

[texttechne]

Hi,

having written the first PR, I must confess, that I've had problems to conform to the different code styles of the different packages.

Hence I would like to propose the following changes:

• decide on one code style 😄 (by the way, I prefer semi-colons at the end of the statement 😉)
• install & configure prettier & eslint in root package
• reformat all packages and commit (of course, this interfers with a clean git history, but better now than never)
• install lint-staged / husky to enforce the formatting & linting rules on every commit
  • https://github.com/okonet/lint-staged

Most likely, you know about all this & haven't had the time, so think of this issue as a friendly reminder 😄

[vobu]

me opens the gate
let the trolls roll in ;)

[petermuessig]

OMG, you said the bad words, @texttechne => semicolons! => 🏃 => @vobu will find you ... 🤣

Till now, we loved the anarchy in our repository and we believe in being the better formatters... 😄 But recently also @vobu added prettier and with that we have maybe started the discussions - the trolls are already in...

I am open to discuss - but honestly, I am not a real fan of it... Maybe I just need some time to look into them and play around with them so they already do what I want and not try to correct me always. It is nothing worse than a prettier which adopts my lovely formatted code... 🤣

[vobu]

hell yeah, i will find you 🤣✌️

[texttechne]

da habe ich ja ein Faß aufgemacht 🤣

Ok, I should have asked before assuming. I did see chaos, but actually only package ui5-task-transpile is in some disarray. Apart from this package all others adhere to their own style definition. The good news: it essentially boils down to the following basic style definitions:

{
  "printWidth": 120,                     <-- the same for every package
  "tabWidth": 4,                            <-- 2 or 4
  "semi": false,                               <-- either false @vobu or just leave it out (default = true) 
  "trailingComma": "none"           <-- either "none" or "es5" or leave it out (default = es5)
}

So instead of defining a .prettierrc on the root level, it must be defined in each package separately. Then you maintain the freedom / anarchy you already live 😄

I've prepared a PR for this setup, so that you can toy around with it.

Arguing for Prettier

To be honest: I'm opinionated about code formatting. So let me argue for the use of prettier just this once. Afterwards I shut up and troll my way...

The best thing about prettier: it's opinionated! 😁
Usually this is not a good thing, but in regards to code formatting it's bliss. Because it's opinionated discussions about code style are futile. The tool decides, so that user opinions don't matter!

The tooling integration is superb! Any IDE knows how to use prettier (install a plugin once), while the minimal configuration for the essential questions (semicolon or not 😉) resides in the project. In the end its just a npm dev-dependency and can be executed by command line => completely automatable (CI/CD).
And with the help of lint-staged you can ensure that code formatting will stay consistent: it automatically formats staged files before any commit.

In conclusion: With prettier, editorconfig & lint-staged we are able to completely automate code formatting. And since this is a build-tooling repo: Let's automate whatever is possible to save time & preclude mistakes / errors.

[vobu]

In conclusion: With prettier, editorconfig & lint-staged we are able to completely automate code formatting. And since this is a build-tooling repo: Let's automate whatever is possible to save time & preclude mistakes / errors.

amen to that.
in fact, sir peter and me were already discussing on a "ui5 prettier" config, aligned both w/ best practices and the ui5 guys code formatting recommendations.
might get born over the holidays 🎄 ☃️

[lennart-m]

@vobu are there any concrete plans for this? I'm asking because I also have something like this on my to-do list. But I'm thinking about a specific prettier plugin that also correctly formats XML bindings... probably not that easy as the UI5 BindingParser is probably not usable for this.
I saw there is https://github.com/marceloschreiber/prettier-plugin-ui5view but it doesn't seem to do very much.

[texttechne]

@lennart-m it's just XML, isn't it?
Then @prettier/plugin-xml should do the trick.

[lennart-m]

@texttechne well, for the XML part it should be okay to use plugin-xml, though I'm not very satisfied with the indentation produced by this plugin; it seems quite random.
But it would also be helpful if the XML binding could be automatically formatted. Maybe not for simple value bindings, but if you have formatters and multiple parts then it's a bit tedious to do the formatting yourself.

[vobu]

just publicly FYI: no timeline (and currently also no plans as in "to do", "steps", ...) yet.
@texttechne was so kind to lay groundwork in #374, but given that we (the community) have not aligned features, requirements and goals with the UI5 core team (yet), I'm hesitant to move forward -> probably a good topic for a community-call or similar @petermuessig?

[petermuessig]

@texttechne - as a first step I will go ahead with the .editorconfig this is good to have. I will also check-out prettier a bit more in detail...

[petermuessig]

Coverted into a discussion - as this is more the nature of this topic now.

The .editorconfig and prettier setup has been added and is also active to format the code before submitting. But there are still two parties in the game - Volker who likes no semis and Peter who prefers semis - so the project code formatting config is different... :-)

[petermuessig]

Prettier is used int the repo since quite a while - closing discussion