add .editorconfig to set some basic coding styles

[rudyhuyn]

To maintain consistent code style between contributors and simplify merging, the solution should provide a .editorconfig to set some basic rules (already used by the current code source).

• use UTF-8 with BOM (some files are without)
• use CR-LF
• use Space to indent (sorry #teamTab)
• trim trailing whitespace
• be sure to add a new line at the end of files.

Documentation

[HowardWolosky]

This is great. Thanks Rudy. We had just been discussing yesterday that specific issue about the BOM and our desire to find a way to help enforce it stay there. How timely.

[janisozaur]

I'm curious why BOM is preferred?

I also have concerns about explicitly stating crlf in some of the files, why is that needed? I would imagine this will clash with whatever is the default on the platform and respected by git. Additionally, what's the reason for selecting crlf instead of the more commonly supported lf?

[HowardWolosky]

Reasonable questions, @janisozaur.

For BOM, it's because our team has now twice encountered a problem (once before public release, and again more recently in #197) where VSTest failed to correctly read embedded Unicode characters, and the failure reason wasn't immediately obvious. In this commit as part of #197, Brett made the change from the embedded Unicode character to using the escaped character sequence, but that was only necessary because the BOM got lost during his editing session.

So, I'll pose you the counter -- do you have any specific objection for ensuring the BOM is there?

As for crlf, this one I'm less set on. If you're concerned about it, I want to hear more. Please open an issue so that we can have a discussion with the community on the impact of the current decision, and whether we should keep crlf, change it to lf, or just remove the end_of_line option entirely.

Thanks for your diligence and interest!

[janisozaur]

do you have any specific objection for ensuring the BOM is there?

I sometimes do things to sources when playing with them on various setups, that includes concatenating files. BOM gets in the way and most stuff already expects and assumes utf8, so there's little need for BOM. Some Windows users in the projects I contribute to switched some option in MSVC to behave like that or maybe it was a change that came with some recent MSVC update. Either way, there's no BOM in our utf8 files, no tool complains and I prefer it that way. Most tools I've seen prefer no BOM and it is often being switched from commit to commit, having no BOM in my experience leads to less churn. I have no idea what vstest is, so I can't comment on that.

My take on end_of_line is it should not be set, based on the presumption that git client already handles that. In the odd case where someone has misconfigured client and commits alien crlf, it should still be corrected in a future commit to git-native lf, so it can be correctly processed by others, contrary to a scenario where lf was chosen as default.

[HowardWolosky]

vstest is the test execution harness that runs our UT's in our build pipeline.

I've opened #237 to allow for open discussion on the impact of specifying a default line ending for these files. Please join the discussion there, and once a decision has been reached within there, a PR (if necessary) can be created.

Thanks!

[rudyhuyn]

I'm ok with janisozaur, if we want to support Mac and Linux users, we can remove end_of_line = crlf