1

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?

user3834459
  • 160
  • 6
  • 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 05 '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 05 '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 05 '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 05 '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 05 '18 at 18:05

2 Answers2

3

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 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 05 '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 05 '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." http://repl.it uses gcc version 4.6.3. – Robert Harvey Jul 05 '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 06 '18 at 17:18
1

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!

esoterik
  • 3,879
  • 3
  • 13
  • 22
  • 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 05 '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 06 '18 at 06: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 06 '18 at 07:30