New team, same discussions...

* Why should we use cmake? It is way better to add visual studio project files to the repository and allow everyone to mess around in the compiler setting dialogs. Nobody needs cmake if not targeting multiple platforms!
* clang-format? What kind of black magic is this? It is way better to manually try to stick with each source file's existing formatting - regardless of how messed up it is - and manually check that from time to time!
* Why should we use the latest visual studio 2019 compiler, if 2017 and 2015 do just fine? This way we can save license fees!

/irony off

Just to mention a few highlights...

*facepalm*

Im not a huge fan of cmake and I like to stick to make still with a proper requirements documentation

But anything beats pushing studio files and working with that

You've forgot /irony ON

@iiii that's the default setting

@electrineer explicit is better than implicit

What about just using clang as a compiler? That would save even more license fees...

@halfflat there is always disagreement about how to format this and that detail, regardless of how detailed or strict you define your code style guidelines... Until you introduce an automatic code formatter like clang-format. That's because of people don't have to spend time on formatting any more they stop thinking about these details, but instead think about stuff that really matters. It is a tough transition for anyone who is a formatting hardliner who likes blaming others for not following the code style to the point. But even those will thank you at some point, believe me. I used to be one of these guys in the past.

@halfflat @kraator Usually you can ecplicitly disable formatting for a few lines....

In any (good) formatter.

Readibility is highly subjective sometimes....

A common ground aka style guide assures that everybody has to compromise somewhere so that no one gets extra treatment.

Which is fairer than requiring everyone to respect each other's style equally... Which is impossible.

Think of a team with >3 people. Everyone has their preferred style. This spells disaster... Readability suffers for everyone - as everyone thinks their style is the best.

The "I want it my way" moping and "this not how I do it" bitching is pointless.

Kindergarten is somewhere else, this is work. :/

(I had these discussions too many times. When you want to work alone and be responsible for yourself - work as a freelancer.)

@halfflat It usually isn't very common to write down code that needs special formatting attention. Sure there are cases like matrices, where you need to see the NxM grid in source code rather than just a list of comma separated value, but if you need to you can always enforce manual formatting for a code region.

Most cases however where developers feel the need to adjust formatting to match their personal taste of readability are a waste of time. Think about the number of hours spent discussing about formatting details and personal preferences, arguments with colleagues who didn't follow the guide, and teaching new team members the set of rules (which they dislike).

All that disappears with automatic code formatting. I've had your point of view a couple of years back. My main issue was trust. In didn't believe how damn good these tools are today and how well they do what I would manually do the same (or close enough). Once you get used to such tools you don't want to go back.

@halfflat put the goddamn parentheses!

Spaces are not parentheses.

@halfflat I've never heard about that idea of formatting code. There is no such option in clang-format for good reason. As @iiii already said: use parentheses ffs or at least learn operator precedence. This is basic knowledge in any language.

std::cout << a++ * b + c;

Head -> 🧱

@halfflat math is fine. there are specific precedence rules and you don't need spaces to parse it visually. But the second expression is garbage regardless of spaces, such expressions should not pass any sane review.

@halfflat readability.

@halfflat wrong answer ;)