I'm working on a large codebase whose core modules are in C and extension modules are in C++. We have a coding convention for C code but I'm being told that we need to enforce the same coding convention for C++ modules.

As a personal preference I dislike using an ANSI-C style declaring variabile at the beginning of the scope instead at the first point of use (that forces me to navigate backward each time to see what a variable type is and I think it's also way more error-prone since you forget variables if the function has many) and I also dislike not being able to use smart pointers and deallocating lots of things in a non-RAII fashion if an error comes up.

My boss says that style consistency matters more than anything else but we disagree on this point (if we have the tools to render our C++ modules more clear and readable ~ thus maintainable.. why not using them?).

Is this common in a large mixed C/C++ project?

marked as duplicate by Robert Harvey, Bart van Ingen Schenau, Doc Brown, Greg Burghardt, gnat Jul 5 '18 at 18:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    I guess that same coding convention also applies to the makefiles, supporting scripts and everything else written in a language other than C. Right? – Bart van Ingen Schenau Jul 5 '18 at 17:04
  • that forces me to navigate backward each time to see what a variable type is -- Sounds like you need a better IDE. Most IDEs worth their salt will tell you the variable type if you hover your mouse pointer over the variable. – Robert Harvey Jul 5 '18 at 17:04
  • 1
    that forces me to navigate backward each time to see what a variable type is- sounds your functions are way too long, if you cannot see the type, this means your functions don't fit completely on the screen. Better work on that. – Doc Brown Jul 5 '18 at 17:21
  • +1 on @DocBrown's duplicate flag. I think the additional considerations you need to make for managing memory in C/C++ differ than comparing, say, Java and C++ where Java is a garbage collected language. – Greg Burghardt Jul 5 '18 at 17:57
  • 1
    There is an important aspect that the question does not clarify: are we speaking of independent executables running in their own address space ? Or is it about a mixed language programming, the core being in C and some compilation units, libraries or DLLs being in C++ (or vis-versa) ? – Christophe Jul 5 '18 at 18:05

Unfortunately, C++ code that is very C-like is fairly common in mixed code bases. However, that is almost always by accident and sloppiness rather than by policy. There is no point in using another language if you aren't going to use that language idiomatically, and take advantage of the abstractions it provides to make code more robust and easier to write correctly. You may as well just write your entire code base in C (which isn't the worst idea, by the way). Not to mention, things like variable declarations at the top haven't even been the standard in C since C99.

  • Variable declarations at the top are a common-sense thing. If the variable is used throughout the class or module, put it at the top. If it's used one-time (e.g. a loop variable that needs to survive the loop), put it before its first use. It was never really a "standard." – Robert Harvey Jul 5 '18 at 17:11
  • 2
    @Robert, do you know C? All variables used to be required to be declared at the top of a function, before any other statements. You couldn't just "put it before its first use." You had to put it before everything's first use. – Karl Bielefeldt Jul 5 '18 at 17:19
  • 1
    Ah, you're right. C89 worked that way, iirc. The versions of C that I've taught in class have never had this "problem." repl.it uses gcc version 4.6.3. – Robert Harvey Jul 5 '18 at 17:19
  • To be a bit pedantic, variables had to be defined at the beginning of a block, not necessarily at the beginning of the function. – OldFart Jul 6 '18 at 17:18

This is dangerous!

Using a convention or paradigm without understanding why the convention exists will lead to bugs and bad code; this is known as Cargo cult programming.

For example in straight C with malloc/free, having a single exit point for each function was considered a best practice; RAII, in C++, renders the single exit principle obsolete. Using, or continuing to use this paradigm in C++ puts unnecessary restraints on your code; it harms readability, can complicate code and introduce bugs.

Not updating your standards/conventions is also dangerous; modern C doesn't require variable definitions at the top of the function anymore; unless your using C89 don't use conventions designed for C89, update them to modern conventions for your modern language!

  • This is all good if you assume that the C++ code is independent of the C code. But if you use RAII in a C++ library, but you have to invoke it from a C compilation unit using a C wrapper, it might very well backfire, as the C++ semantic is not enforced across the whole code – Christophe Jul 5 '18 at 18:13
  • @christophe I would contend that the very act of 'wrapping' C++ to be usable by C code already prevents that from being an issue (exceptions aren't quite that automatic though) – Bwmat Jul 6 '18 at 6:45
  • @Bwmat I agree. But the question is not about judging the architecture; it's about understanding the constraints of a specific project. The op said core is in C and extensions in C++. So I imagine a plugin architecture, where the plugins are dlls in c++. Interestingly this could explain the manager's retrograde position against raii, which would otherwise not be rational. We don't know the project constraints. Take the example of macos: c++ code is routinely wrapped into objective-c. Or embedded software, where a kernel part could perhaps not be written in c++ because of ABI constraints. – Christophe Jul 6 '18 at 7:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.