1

With 'global variables', I mean

  • Variables on namespace level
  • Static data members in classes
  • Static variables in functions

In a big C++ project I would like to have a mechanism (like a compiler option) to prevent such data in most parts. A compiler error or warning would be nice. Of course, at one point you have to instantiate your classes.

Conceptually we have the notion of "runnables" which is the code encapsulation. While provided by the platform project they can be 'instantiated' and connected by the downstream project. Unfortunately, since usually there was only one instance of a type, devs used a lot of globals or statics. Needless to say this isn't good practise and you run into problems when doing two instances of a class later.

It's ok to have only one build preventing this (we have GCC, Clang, VS and GHS). I guess a linker option isn't applicable as the executable is linked in the downstream project and they instantiate the 'runnables' on namespace level. Another idea would be to search the object (.o) files if they contain something for the data segment, but I'm uncertain how to do that.

Borph
  • 121
  • 3
  • 8
    Sorry, but it doesn't work that way. You minimize global variables by having the discipline to do so. The computer is not the boss; *you are.* – Robert Harvey May 20 '19 at 14:57
  • @RobertHarvey you are right, I just want to 'teach' some discipline :-) A warning would already be a good reminder! – Borph May 20 '19 at 15:07
  • 1
    Are there no linters for C++? – marstato May 20 '19 at 16:12
  • 1
    what do you call big ? and why do you want to avoid them ? and how would you define your constants (in particular constexpr in classes ? – Christophe May 20 '19 at 17:00
  • @marstato tidybot – solarflare May 21 '19 at 02:09
  • @Christophe good point with constants, I guess they would be less of a problem when you do two instances of a class. That's also what I want to address (shared data between instances). – Borph May 21 '19 at 08:41
  • I'm fairly sure this can be written as a clang-tidy check, but I don't believe it exists yet. – Justin May 21 '19 at 14:51

2 Answers2

16

In a big C++ project I would like to have a mechanism [...] to prevent such data in most parts.

There is such a mechanism. It is called code reviews - especially when done by the experienced guys in your team. Use that, and you will sucessfully avoid any unnecessary global variables in your project.

(And yes, I am aware that is probably not the answer you like to hear, but I am under the impression you are looking for a technical solution to a people problem - that almost never works).

When you just enforce a rule like "no globals" (or "no goto", or "every function needs a standard comment") by some tool, some developers will find a way to circumvent it - usually in some horrible manner which follows that rule literally, but does not increase any maintainability. If you teach all your devs why globals are not a good idea, which alternatives exist, and in which exceptional cases globals are acceptable, then you don't need a tool to enforce the rule. A code review is probably the best instrument we have to teach this knowledge and make sure such rules are applied in a way which makes sense.

See also: How would you know if you've written readable and easily maintainable code?

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • You are right - a technical solution to a people problem. Still sometimes needed, that's why MISRA rules get checked by static code analysis. – Borph May 21 '19 at 08:44
  • 1
    @Borph: I see your point, but AFAIK the MISRA standards contains a lot of formal rules which can easily be violated accidentally, even by experienced programmers. Unnecessary usage of globals is something one does not violate "accidentally". – Doc Brown May 21 '19 at 14:15
2

Some things can definitely be enforced by the compiler. Some other, unfortunately, cannot.

A good alternative to compiler warnings / errors is using a static analysis tool, configured appropriately according to your desires.

All "automated" solutions must be used as a tool during (the preparation of) a peer review.

As it was already suggested, the problem of global variables is more of a "mentality" problem, not related to syntax or anything. Keep reading about how you can deal with it (most important, using a static analysis tool and peer reviews, based on internal company regulations).

However, all the above will work only once there are some rules implemented at the workplace.

  • There must be some "development process" implemented, specifying things like:
    • how requirements will be written, to which level of detail;
    • how the source code must be written;
    • how everything will be verified and tested.
  • regarding the "how the source code must be written", there must be a coding guideline about it implemented in the company.

There are many coding guidelines available, some of them freely available, some for some fee. You will find many of them on the internet. Study them and see what fits best to your environment.

A good starting point is the MISRA coding guidelines. They were created to be used by the automotive industry, so they tend to be very strict. However, they will give a good insight about how to think.

You will also find interesting information (not necessarily regarding global variables) on the PC LINT site. I sometimes "relax" reading the "Bug of the month" section.

virolino
  • 572
  • 4
  • 12
  • +1 for the static code analysis hint. Experience is not big enough among reviewers, even architects, sadly, so that project level rules could indeed steepen the learning curves. – Borph May 21 '19 at 15:21