Expectations - Coding Standards

[andywestken]

This thread follows on from one of the posts in the thread "Expectations":

https://cplusplus.com/forum/lounge/285833/#msg1243093

Duthomhas wrote:

Those are all good ideas, but unless you have a document spelling out what is and isn’t correct you have no standing to enforce it.

We do have coding standards but the problem is that this time we didn't make them tight enough! :-\ I do think it can be hard to set the standards at the right level, to keep things under sufficient control without inadvertently patronising people.

Duthomhas wrote:

Everything is ultimately a business decision.

Another problem we hit is that we recently lost our most technical senior manager and I now feel that decisions are being made for fuzzy "business" reasons rather than technical reasons. As a result of this technical debt is ramping up rather faster than it used to. :-(

Duthomhas wrote:

It might be worth reading through https://isocpp.org/wiki/faq/coding-standards

Thanks!

We are aware of ISO C++ pages, notably the Core Guidelines:
https://isocpp.github.io/CppCoreGuidelines/

Another starting point for our coding guidelines is the book "C++ Coding Standards"by Sutter and Alexandrescu (with some modernisation)
http://www.gotw.ca/publications/c++cs.htm

[andywestken]

Added later to the "Expectations" thread:

seeplus wrote:

Definitely! There should be a document detailing what is expected as coding standards (detailed even to the level as to how variables, types etc are named - using underscore, capital letter, how braces are laid out [which can be a very emotive issue!] etc etc). Every programmer should have to follow this as part of their contract.

I am increasingly of the opinion that standards do (sadly?) need to be pretty tight.

And I definitely agree with the view that code needs to be consistent in a given codebase. That consistency is more important than the specific details.

I hadn't thought of making compliance to standards contractual, but looking back that is a very tempting idea!

[andywestken]

And a bit later:

keskiverto wrote:

The list is less important than comprehension why each entry is on the list.

This does seem to a big problem in some cases.

Some developers are in such a rush they cut corners leaving problems for others to solve in the future. So motivating them to take care and do things that they see as a pointless waste of their time is next to impossible.

[jonnin]

Well, that is the heart of it, for sure.
everyone wants easy to read, clean, up to date, bug free, elegant, perfect code for everything. And they want that new feature done in 2 days, too.

Something has to give... time is money, as you rack up expense spending forever on doing it right, or fixing bugs/problems from cutting corners costs as much or more later. If you want to get your program out there generating income, you have to finish it before someone else grabs your idea and beats you to market...

cutting corners somewhere is going to happen. The rush is usually caused by management, who put deadlines on stuff that doesn't account for all the stuff you want to do to make code awesome, it just accounts for the minimal time to get it to market mostly working.

[seeplus]

such a rush they cut corners leaving problems for others to solve in the future

That should be outlawed in the coding standards which they are obliged to follow.

But I've never worked in 'public' program development. Only in in-house and bespoke development - and I guess things are a bit different if you do public development....

[seeplus]

the book "C++ Coding Standards" by Sutter and Alexandrescu

There's also 'C++ Programming Style' by Cargill. But again this is out of date (1992 - before even C++98!).
https://www.amazon.co.uk/Programming-Style-APC-Tom-Cargill/dp/0201563657/ref=sr_1_1

[seeplus]

If you do bring in detailed formal coding standards, expect some opposition! When we did this quite a few years ago, the 'Wars of the Roses [UK 1455 - 1487] https://en.wikipedia.org/wiki/Wars_of_the_Roses ' had nothing on this! Threats, resignations, false accusations and treachery were all encountered. It was not pleasant. But now all new recruits have to formally accept these standards before they are hired and non-compliance/conformance is a disciplinary affair which in extreme circumstances can lead to dismissal.

Have fun!

[George PlusPlus]

Re: coding standard....that is THE touchstone Programming Holy War subject. Formatting and 'proper' braces placement are two of the most volatile Jihad inducing precepts.

+-----+

One thing that is generally not explicitly stated or even considered regarding coding standards (at least not that I've noticed):

Using more than one compiler when writing and testing code. Code that compiles and runs with one compiler should work with another, but there are edge cases when it doesn't.

In my experience, limited as it is, WinAPI code is the biggest offender. Really strange is the usual "won't work" issue is with MS Visual Studio. WinAPI code that compiles without any apparent problems with, say, MinGW can have issues when trying to compile with VS. Even if it compiles minor runtime problems can crop up.

99.9999% of WinAPI and C/C++ code is transportable between compilers. It is rare indeed when it isn't.

Especially ticklish is when code is compiled for x64 vs. x86. Subtle runtime errors can creep courtesy of POD data types having different storage requirements. Pointers can have different sizes x86 vs. x64.

+-----+

I'm 'lucky' in not being a work-a-day programmer, I am a self-taught hobbyist. I have no corporate required deadlines to meet, I can leisurely spend time dinkin' around with aspects of C++/WinAPI that interest me.

When learning some new (to me) feature in C/C++/WinAPI I write a lot of test code, little snippets to poke around to understand what can and can't be done.

Some I even post on GitHub.

One of my earliest bits o' code is a simple C++ random toolkit header, to help using the C++ <random> library as easy to use as C's srand/rand functions for most trivial uses.

https://github.com/GeorgePimpleton/cpp_misc_files/tree/main/Random%20Toolkit

I freely admit the idea is not mine, I shamelessly stole it from an ISO C++ Committee working paper. My sole contribution is to augment it, giving it more versatility.

[George PlusPlus]

One particular thing that annoys the *BLEEP* out of me, not using braces with one line code blocks resulting from for/if/etc. operations. IIRC there are other languages where white space is valid for differentiating code blocks.

Without braces code like this won't work as intended, the pre-processor and compiler ignore the white space:

#include <iostream>

int main()
{
   std::cout << "Enter a number less than 10 or greater than 100: ";
   int x { };
   std::cin >> x;
   std::cout << '\n';

   if (x >= 10)
      if (x > 100)
         std::cout << "More than 100, Thanks!\n";
   else // not the else intended!
      std::cout << "Less than 10, Thanks!\n";
}

Using braces even on one line blocks of code what is intended becomes easily noticed:

#include <iostream>

int main()
{
   std::cout << "Enter a number less than 10 or greater than 100: ";
   int x { };
   std::cin >> x;
   std::cout << '\n';

   if (x >= 10)
   {
      if (x > 100)
      {
         std::cout << "More than 100, Thanks!\n";
      }
   }
   else // fixed!
   {
      std::cout << "Less than 10, Thanks!\n";
   }
}

Sure, the code is more 'verbose', yes, this is a picayune nit-pick, yet has the advantages of easily seeing where code blocks start and end IMO outweighs the wordier style. Without the braces adding another statement after line 13 in the original code snippet noobs get fooled into thinking the added statement is part of the code block. *BUZZ!*

[Peter87]

I think programmers should be expected to be able to put their own opinions aside and follow whatever coding standard that the project/company uses.

keskiverto wrote:

The list is less important than comprehension why each entry is on the list.

andywestken wrote:

This does seem to a big problem in some cases.

I think the list itself is very important. It's what makes it easy for people to follow, even if they don't understand or agree with the reasons.

Sometimes there might not be a very strong argument why something is done in a certain way so it's more about making a decision and being consistent in that case.