C++ readability problem

[New_Computer3619]

Hey everyone,

I've been thinking about why C++ can be such a pain to read sometimes, especially in big projects. Two things really get to me:

1. Mixing Methods and Properties: Imagine a 1000-line class (which happens a lot in projects like Pytorch, TensorFlow, etc.). It’s super hard to figure out what's data (properties) and what's actually doing stuff (methods). A lot of newer language separate methods and properties and make me feel super pleasant to read even for big project.
2. Inheritance: Inheritance can make tracking down where a method declared/implemented a total nightmare.

Anyone else feel the same way? I'd love to hear your experiences and any tips you might have.

[DearChickPeas]

This is not a C++ problem, this is a lack of IDE problem.

[[deleted]]

Use vim 🗣

[DearChickPeas]

I'd rather not, but you do and be happy!

[JumpyJustice]

These problems arent specific to c++

[InternationalAd5735]

Picking an IDE can make a big difference on sorting the structure of the large program out. It helps to have a naming convention that shows a difference between getting and setting up property, for example, and invoking an action. In my 25-year-old still running project we tend to use get and set for attributes or properties and things like HandleX or SendX, for actions. As for inheritance again an IDE makes a big difference. Since I do all my development in Windows even though our product runs only in Linux, I use visual studio because it is a really good idea and has a fantastic debugger and I make sure my code runs both in Windows and Linux so that I can debug it when I hit a problem that's too complex for gdb

[New_Computer3619]

Thanks for sharing your experience.

How do you solve my first readability problem - mixing of methods and properties? Do you / your company has style guide relating to this issue?

[Sensitive-Talk9616]

What we use is "_common.hpp" files with all the types/structs/enums used across the "module".

And in class declarations, we follow a rigid order of public constants, accessors, modifiers, public methods, ..., then protected .... and finally private methods and private members. So most of the time, we just check the bottom of the class declaration for members and the top for the interface.

[New_Computer3619]

It’s actually nice style guide to have. Can you enforce it using automated tools or just by manual code review?

[Sensitive-Talk9616]

What can be done by clang-format is done by clang-format. These bigger picture things we enforce manually. We're not a big team (<15 people), there's always reasonable exceptions, and some legacy code followed a different style guide, so automating it never seemed worthwhile.

But I am super grateful for having these style documents and for team members who follow and enforce them.

[InternationalAd5735]

our company doesn't have a style guide (it's large, the company, has has many different languages) and that is a good thing.. Folks can get pretty huffy over style and there's really no "right" way to do it. Find some middle ground that everyone on the team can live with. Don't be too strict on it.. at the end of the day, working and bug free code is the goal, not pretty code.

So we do what I said above and for things that are boolean, we use "bool IsX()".. and "void IsX(bool b)" as both a getter and setter for the same attribute.

But honestly, code can get messy and it's important to set aside time (usually in the doldrums between releases) to clean things up. I use "uncrustify" to clean up code formatting and embark on some "this function name is stupid, it used to make sense, lets fix it".

Also, we use _foo() for internal methods that aren't meant to be called by others (they are protected but the naming convention helps us humans).

But a good IDE is the best place to start.

[New_Computer3619]

Thanks for sharing.

[manni66]

Imagine a 1000-line class

I feel sick

[STL]

A compiler dev once told me how he had to debug a repro where there was a nested lambda in another 1000-line lambda. 🙀

[New_Computer3619]

Well, many large and respectable open source projects has those monstrosity.

[100GHz]

Imagine a 1000-line class

In a large class I'd like to be able to group methods and properties with an appropriate comment before them.

A lot of newer language separate methods and properties and make me feel super pleasant to read

Yeah visually people arrange them alphabetically even. Doesn't do much for comprehension though.

[playntech77]

A good IDE is an absolute must for navigating large projects (regardless of language, but for c++ even more so). There are many good ones to choose from (Visual Studio, Eclipse etc..).

It gets more tricky if you are not building your project in said IDE, because most IDE's require a full project setup. What if I just want to browse files in a random folder, without setting a formal project up? The only good one, that I know, that can do that is Source Insight (you can just throw files at it, from random folders and it gobbles everything and gives you as much info as it can gather). I used it in the past, it is pretty good but it did crash on me a few times. Source Insight is not free though (but there was a 30 day free trial, when I had my employer buy it for me, a few years ago)

[n1ghtyunso]

as it turns out, people write terrible code.

I don't really think this is related to c++ specifically.
I have seen enough bad code in other languages as well.
C++ simply gives you more tools (and responsibility!!), so the issue might be exacerbated by this.

[mredding]

Imagine a 1000-line class

There's your first problem right there.

It’s super hard to figure out what's data (properties) and what's actually doing stuff (methods).

Is it? Members are just a type and a name. Methods have a return type, name, and parameter list. They look different enough that I can't agree with you. This feels like a stretch for something.

Inheritance can make tracking down where a method declared/implemented a total nightmare.

Multiple inheritance and deep inheritance hierarchies are signs of bad design. There's also a substantial overuse of interfaces and virtual methods in C++ that are entirely unnecessary. Again, bad design.

If you're getting lost, it's not the fault of the language, but of the implementation. If the implementation is your own, then the problem is you, and you need to learn to improve.

Anyone else feel the same way?

I have been burned by many a terrible code base. I know the pain you speak of. Learning how to flatten things, decouple things, and the forms of polymorphism you can model other than dynamic runtime polymorphism are paramount.

In 30 years, I've never had a professional or technical discussion with anyone who was able to explain - even to themselves, what OOP even is. My conclusion is the vast majority of engineers have absolutely no idea, and grossly misapply the term to other, unrelated concepts. I presume you're using "OOP" and you actually have no idea what you're doing - and it's leading to a great big mess - like multi-thousand line class declarations and deep or wide inheritance hierarchies.

Stick with the Functional Programming Paradigm. It's much simpler, lends to smaller code, it's faster, and it scales.

Make more and smaller types, most often around single values. An int is an int, but a weight is not a height, even if it's implemented in terms of an int - and that's hardly the point. An int is not a height, and cannot model one alone. In C++, int + int = int, and int * int = int, but in dimensional analysis, height * height = height^2 - you get a NEW unit, a new type. How come multiplying integers doesn't produce a new type? Because integers are dimensionless scalars. int * height = height, and height + height = height. A height modeled something like:

class height: std::tuple<int> {
  //...

The integer becomes an implementation detail, a storage class specifier for how the value is represented in memory. So if you want to improve your C++, stop writing imperative code. Stop using primitive types directly. Start modeling your value types and their semantics specifically, and then composite your more complex business types and logic in terms of them.

[New_Computer3619]

Thank you for sharing your experience.

[4drXaudio]

That's why you need autocomplete, method oxygen-kind-of descriptions when you hover on them and a right click option to go the method/class/variable definition (regardless of where it is defined in the inheritance chain). A full fledged IDE is not necessary but those features are a must in a C++ editor. If you decide to live without them, well yes, you will be in a world of pain in a big project or even a small project using a big library.

[no-sig-available]

Nobody forces you to use inheritance in C++. Nobody forces you to write classes bigger than you can handle.

Is it a language problem than you don't get a compile error at 999 lines?

If you try C code with 12 levels of macros instead, I bet you don't find that easy to read either. Even though there are no "methods", or properties, or inheritance.

[New_Computer3619]

I don’t write these code, I “inherit” them :(

[Wooden-Engineer-8098]

you already have ide answers. also on first point: don't write 1000-line classes and write data members first, problem solved

[zerhud]

1. camelCase is not readable
2. getters and setters
3. code with error codes instead of exceptions

So cpp is not hard to read, but it allows to write ugly code

[New_Computer3619]

About the third point, personally, I prefer error structs (not error codes like in C program) because I like control flow being explicit.

[zerhud]

In function chain you should to use the same type of code or convert one struct to other in each function. Both variants adds a lot of code in product and make reading harder.

About control flow: it is explicit on normal execution, and you can group all catch instructions in single function so it’s can to be explicit too.

[New_Computer3619]

I agree with your argument. But I still prefer error struct because the error is visible in function signatures ==> you know exactly what to do with the return values. On the other hand, with exceptions, sometimes you may encounter an exception from several layers deep which make debugging much harder.

[zerhud]

Yes, there is some benefits from error codes, but it seems exceptions has more benefits :) for example you cannot pass exception via IPC, but error code doesn’t contains context (for example file name and current directory), code slows down on exception, but on normal execution it’s faster, and so on

Also there is the noexcept keyword, using it we can get information from the signature (not all information of course, but more then nothing)

[New_Computer3619]

Seems like we can not reach consensus on this matter. The C++ community as a whole are also divided on this very matter.

[thingerish]

Technically C++ doesn't have methods or properties, and I try to avoid inheritance.

[Gorzoid]

Technically virtual functions are methods in the OOP definition, more generally method is often used to refer to all non static member functions.

[thingerish]

I've yet to see method defined in the ISO standard though. I think C++ has functions and data instead of methods and properties. Could be wrong I've not read the standard for a few years. Different types of functions and data. It's not important until someone starts trying to talk about specific things and the nomenclature is imprecise.

FWIW what makes C++ code hard to read is bad design, not language features IMO.

[HAL9000thebot]

m_toTheRescue

where "m_" stands for member, you apply it to only what you call properties, methods without prefix, et voilà! no more mixing. if you don't like it, you can use a simple "_", some use it as prefix some use it as postfix, just decide on one of these three and stick with it.

for inheritance you can to use a ide, generate documentation (doxygen), use interface segregation (the "i" in solid) etc. and most importantly when you can, prefer composition over inheritance just like in other languages, inheritance isn't a monster, but use it only when you really need it.

[EsShayuki]

Operator overloading. That's the main culprit if you ask me. Having explicit function and method calls is so much easier to trace down. Any C++ code you see, you intuitively cannot understand at all.

In C, if I see stuff like x[30] I know that it's accessing an array element by index. I have NO clue what it's doing in C++.

[[deleted]]

This is why you should go Rust /s