Doom3 is the proof that "keep it simple" works. UNDER REVIEW

It's not recommended for a beginner to take risk and ignore the Modern C++ recommendations.

 
Are you saying that it's not recommended for a beginner to write code that is easier to fully comprehend? I would say that it should be the opposite, otherwise, if just hiding behind abstractions, there's little hope for ever becoming an expert.

And regardless of the coding style, I don't think a beginner could take on a project like this anyway. Obviously, one has to be some kind of expert to work on a game like this. Whether you use 'auto', initializer lists or lambdas or not isn't going to change that.

In my opinion, this article contains too many opinions, many of them I find invalid (and yes, that is also [my] opinion ;)).

Doom3 implements a hard coded compiler, and as known by C++ developers, it's not an easy task to develop parsers and compilers

Probably not easy but with tools like flex and bison not that hard either.

Until now nothing special differentiate this code from many others using "C with Classes" and criticized by many C++ developers.

Which developers? Some reference to some C++ (game) veteran, maybe? Because I think that the less "expert C++" stuff used the better. In fact, I'm surprised that Doom 3 relies so heavily on stuff like abstract classes and even has such nasty base classes like idClass. But, after all, that's probably Carmack's choice and he is a credible person so it probably worked well for him.

This could really benefit from an editing pass to clean up the language, there are a number of places where it appears to be trying to say one thing, inferred from the context, but the actual words in the sentence say the opposite.

 

As we can observe many structs are defined, for example  more than 40% of DoomDLL types are structs. They are systematically used to define the data model. This practice is adopted by many projects,  this approach has a big drawback in case of multithreaded applications. Indeed, structs with public fields are not immutable.

There is one important argument in favor of using immutable objects: It dramatically simplifies concurrent programming. Think about it, why does writing proper multithreaded programming is a hard task? Because it is hard to synchronize threads access to resources (objects or others OS resources). Why it is hard to synchronize these accesses? Because it is hard to guarantee that there won’t be race conditions between the multiple write accesses and read accesses done by multiple threads on multiple objects. What if there are no more write accesses? In other words, what if the state of the objects accessed by threads, doesn’t change? There is no more need for synchronization!

I don't see why "Classes" help here? Ok you can protect your member variables from access and then add sync primitves into your member functions. But this is a bad way to do concurrent programming. So a better way would be to divide your data to "threads, work, task" -> you name it.

This has been done on the render code i think, and as you can see this can be done equally in C too.

I disagree with a few implications here. For instance, in this article inheritance is seen as something good, and virtual functions too. But nowadays, virtual functions are frowned upon because they can actually become a performance bottleneck (some platforms such as PS3 are really bad at virtual functions and it's best to avoid them if possible). Favor composition over inheritance. Use polymorphism only when really needed.

Virtual functions also seduce programmers to code in the OOP-style, which often leads to code that is not very data oriented (with lots of cache misses, and general memory layout not optimal for cache utilization - which is bad because while both CPU and Memory performance have increased in the past 10 years, the CPU speeds have increased by tenfold compared to memory access speeds, so relative to the CPU, memory has actually become slower - so cache utilization is more important than ever before). What I'm saying is, with virtual functions and classes deriving from one base class, you are tempted to do an update loop like "for each object: object.DoStuff()", with "DoStuff()" being virtual. This is essentially a beginner's mistake nowadays. Especially for entity/game object stuff, one should favour structs of arrays (SoA) rather than arrays of structs (AoS).

Doom 3's code is certainly good for its time and the kind of machines from back then, and good readability/understandability is ALWAYS a plus, but I don't think one should design code in the same way nowadays.

This seems to be almost a defense of "C with Classes" as a justification of our own poor habits because an expert knowingly chose to use similar habits.

It's seems to be saying, "This one expert I saw made something really awesome and he only used X and Y. Therefore it must mean that only using X and Y is the expert thing to do."

Or to put it another way, "I was watching professional racecar drivers, and in the middle of a race, they never used the car brakes! Therefore, not using brakes while driving my car to work must be the professional."

The article also seems to contradict itself:

If 40% of all the structs and classes have a base class, and 30% of the base class methods are virtual, that sounds exactly like "overuse" of of interfaces and abstract classes.

Now, I don't agree that all abstract classes are bad (only overuse of it), but this article says one thing and then contradicts itself a short while later.

 

 

To resume only basic concepts of OOP are used, no advanced design patterns used

Design patterns shouldn't ever be "used", they are ways of describing existing code. I'm too lazy to do so, but I bet if I went through Doom 3's sourcecode, dozens of design patterns would be found.

They just wouldn't be labeled, "cFactoryDesignPrototypePatternInterface". A design pattern is a description of what a class is, but variable names describe what classes are for.

Also, avoiding the use of references and only using pointers? That's laziness (or, at best, an intentional sacrificing of correctness for consistency - even that's stretching it), not some skilled improvement or wise decision. Unless for some reason references weren't available to them, in which case the lack of usage is still not a plus, but working within limitations.