there are coding guidelines made by experts everywhere, even on MS site what is lacking is people adopting them

I think most people who are working alongside others already have their own team guidelines, by necessity. Otherwise code with multiple authors simply won't work. And newly forming teams definitely consider well-known public guidelines like C++CG along with whatever the devs themselves bring to the table.

Even the public guidelines are usually such team guidelines gone "open source". C++CG was internal to one of Morgan Stanley's C++ teams when Bjarne worked there. Dozens of other teams in the same company had guidelines too, some more, some less exacting - they just didn't find it useful to put them on github.

I see many repositories have some kind of guidelines and style rules, however very very few are comprehensive as the public ones.

What I dislike the most is a semi huge repository with not a single code comment.
You are supposed to "precompile" all the code in your head if you whish to make use of it or to contribute.

@helios
btw. I couldn't resist to thank you for your sample solution to the size of DWROD,
I've just updated my code and it feels cool to know no data overflow will happen :)

No problem. I've just been using that pattern so often the past few months I have it memorized.

its a slick fix ^^

our code style is simple with the unusual bullet that says "match the style in the current file you are editing". There are rules, but that one acknowledges the many authors over many years.

jonnin,

That's interesting rule, I can imagine where this could be useful...

ex. when you're using 3rd party code and you don't want to change code style because you're fetching changes from upstream and want to limit changes to functionality only for better tracking purposes.

for ex. if you change style to your own then having control over what was from upstream becomes more difficult (since your style would modify every update)

A few years ago a coworker added a Git hook that ran a linter over the codebase after committing. I got so sick of reverting changes every time I committed because that fucking script wanted to touch every line in every file. I ended up just globally disabling git hooks from running on my machine. And yeah, the reason I hated it was for the reason you bring up. It makes the commit history useless.

I can see running a linter on the codebase at a set period -- say once a month or week, even end of the day -- but every commit?!? That sounds like something I'd do, at first. And then realize after a couple of lint runs it was defeating the purpose of version control with Git, etc.

Was this lintering approved by the Pointy Haired Bosses and Management?

Luckily I don't have to worry about others messing with any of my Git repo code ATM. Any problems are directly and unequivocally My Fault! I do make a lot of 'boo-boos'.

I can see running a linter on the codebase at a set period -- say once a month or week, even end of the day

It depends on what it does. If it's some kind of static analysis tool that tells the programmer about possible issues, that can run often, it's no problem. If it's a tool that reformats the code in some way, it should only be run before new code is added to the codebase in bulk, to make sure it matches the style of the existing code and if it's unnecessary (or impossible) to preserve history. A reformatting tool should never be run on an existing codebase, unless the history doesn't matter.

Was this lintering approved by the Pointy Haired Bosses and Management?

We only check technical decisions with our teammates, not with managers. It just so happens that this guy decided to add the hook on his own.

the frequency and volatility are the key.

if you run one every 5 min on a 500k file code base, odds are it usually just does nothing after the first time, only fixes one file here and there depending on team size and activity. But its changes will mix in with human changes and be more frequent, harder to isolate and validate etc.

if you run it once a month, many more things may have changed, and you get a bigger edit, but its all in one place and infrequent.

running it infrequently with its own name and scripts and all, its just going to change your repo to have an entry that linter changed 53 files at 2am on Saturday, which the team can see it outside of everything else that normally happens, etc. I see no problem with that. Even if it screws something up, its isolated away from normal code changes, easy to undo or something. With todays tools, it can run, test itself, undo & email alerts on any failure, and be all ready to go monday morning with minimal fuss.

It just so happens that this guy decided to add the hook on his own.

Bad enough if the managers had approved the linting, especially without informing the team of the 'feature', really bad IMO for someone to do something without prior approval and knowledge even if only from the other team members.

I am glad I am only a self-taught programming hobbyist who codes my own 'stuff', any screw-ups are my own fault.

I don't "play well with others" in something like a cooperative programming environment and like it that way. I'm very much a cranky old fart. :Þ

1. Coding style

- I make it self-consistent at least, so that if 5 years down the line I want to change the style it is easier to do semi-automatically.

2. Language specific community guidelines - ex. cpp core guidelines such as this one: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

- I read and use the ones I agree with! Which definitely isn't all, by a large margin. I am heavily influenced by a preference to write things in a similar way in different languages (which is why I don't like the excessive use of {} initialisation).

3. clean compile and static analysis - ex. compiling on high warning level and dealing with warnings - ex. static analysis warning and dealing with them

- I turn full compile-time error-checking and, occasionally, run-time error-checking. I don't expect to eliminate all warnings, but I do take note of them and make sure that I understand why they are there. For the work that I do my code is more likely to be mathematically wrong than syntactically wrong.

4. Commenting - ex. commenting functions, classes, variables and namespaces - ex. keeping your comments up to date!

Name the variables well and the only comments that need to go in are why it's not obvious why you did something. Excessive comments cause clutter, and there are enough {}::&&.! in C++ code already.

5. Detailed error and exception handling

I don't use exceptions. I'm running numerical simulations and if something is wrong I would prefer the code to crash rather than continue with nonsensical data. I do, however, try to run checks on the input and stop with a suitable error message.

6. Code design and API design- - this is a wide topic but doing good code design means more thinking and doing less coding.

Draw diagrams before you write code. Write a framework before you fill in the details. Build slowly. Test as you go. It probably takes longer to write the tests than to write the code. If it's a numerical simulation do the results look physically possible. Try to make the code relatively "future-proof": C++ is changing rather rapidly.

I use exceptions to make an app crash less 'unexpected.' I don't recover and continue from an exceptional condition, exception handling lets me document what went wrong and clean up any resources I am using.

Even a transient exception is not worth trying to continue. Nothing I do is mission critical.

I think an exception being recoverable should be the exception. If it's common then the condition should not be an exception, but rather a returned error. More specifically, an exception should be used when the program state broke the contract the thrower was expecting, such that all it can do is throw and hope someone up the call stack can handle the condition, either by recovering or by terminating. For example it's common that operator overloads have no way to signal errors other than by throwing.
An exception that is both common and recoverable suggests an error in the design.
An exception that is common but unrecoverable suggests a fragile system, while the opposite suggests a robust system.

I think exceptions are handy when parsing files.

Every read operation could fail (the read itself or the validation). Instead of having to check the return value everywhere only to pass that value along further up the call stack it's often more convenient to simply use exceptions. That also means I can use the return value for what I actually want to return.

That said, if the "failure" is expected then I don't think exceptions should be used. E.g. maybe I want to try and read an integer and if that doesn't work I want to do something else. I don't consider that to be something that exceptions should be used for. I don't really like the fact that std::stoi throws exceptions for that reason.

Unfortunately it's often impossible for general purpose library functions to know if the "failure" is expected or whether it's exceptional. It depends on the caller.