3 ms·
Let's see how many antipatterns: - Multiple inheritance - Over-abstraction - Excessive identifier prefixing and suffixing - Use of friend - Use of bit fiel
by sacnoradhq 3y ago
Let's see how many antipatterns:
- Multiple inheritance
- Over-abstraction
- Excessive identifier prefixing and suffixing
- Use of friend
- Use of bit fields instead of bools
- Inconsistent mixture of custom and built-in int types
- Direct storage of pointers instead of reference-counted containers
- Custom (and likely broken) _smart_ptr
- Cancerous coding style that adds too many lines
- Functions with 7+ arguments
- Lots and lots of duplicated code
- Inadequate use of const
- Inconsistent coding styles
- class name and base classes at the same indentation level
- Redundant prefixing of directories ~~and namespaces~~ with the name of the project
Edit: My bad, they don't use namespacing at all. It's a flat namespace. At least they don't using namespace std.
- deely3 3y agoHalf of listed antipatterns are completely valid strategies in some situations.
- jiggawatts 3y agoAbout half of those are because of "performance", which in game engines is more important than future-proofing for maintenance that will likely never occur.
- _def 3y agoAnd it still was very successful as a game. I think this is a great example of "perfect is the enemy of good", especially for game development.
- bhouston 3y agoSounds like a real world project that focused on shipping a good game rather than have perfect code. There is a reason perfectionist devs do not run big projects. They focus on minutiae rather than the big picture. Even in my own experiences, one of my most successful projects (eventually acquired by Amazon) was a quickly written hacked together project that solved a big issue well. Over time it became better engineered but it taught me successful projects are about market fit, not code quality, especially super minor things like antipatterns.
- Xeamek 3y agoOr maybe, just maybe, 'good practices' simply changed over the span of literally 20 years? Naah, it must simply be those 'perfection vs practicality' dichotomy again. ...Not to mention that your point is the definition of survivor ship bias. Maybe the devs actually were super mad at themselves how the codebase looked cause it slowed down their development. Maybe they initially had 3 more times the ammount of anti-patterns, but they reduced them. Or maybe that's how their roll, but the fact that this code shipped is almost insignificant when it comes to judging its quality. We could spin infinite ammount of examples where bad code works, where good code fails, where bad code fails and were good code works. How about we actually talk about arguments instead, though?
- deleted 3y ago[deleted]
- aflag 3y agoI don't really think good practices changed that significantly in the last 20 years. Good practices must be seen like guidelines, not a strict dogma. They are mostly for the benefit or other humans to read and modify it without introducing (many) bugs. So, it's always a balance between the time you can reasonably imagine that code base will still be relevant, the number of people changing it, how much harder certain bending of the guidelines make it to change the code in future, etc.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- extrememacaroni 3y agoPeople who work on such projects tend to focus on finding solutions to difficult problems and many things that you would consider weird or bad could be there because they were part of a solution, either at the time or sometime in the past in a previous project.
- ExoticPearTree 3y agoGood today is better than perfect tomorrow.
- nemetroid 3y ago> - Direct storage of pointers instead of reference-counted containers Overuse of reference counting is an anti-pattern and a performance killer.
- nomalloc 3y agoIf anything, this is a perfect example of how little these things actually matter in the real world. This game alone sold over 2.5 million units and kickstarted one of the most popular franchises in gaming today. I always have a feeling this type of comment must be necessarily written by someone who hasn't shipped anything of substance in the industry. It's trivial to point out irrelevant minutiae like this as opposed to having an in-depth discussion about the merits of the terrain rendering system or, you know, literally any of the hard problems the game is solving and that actually contribute to making it a technical success.
- nmfisher 3y agoHave you shipped many game engines?
- jamesu 3y agoBit fields saved me an immense amount of pain when packing together state variables for a renderer, so I wouldn't write them off as being bad myself.
- naillo 3y agoMakes me think I shouldn't care as much about perfect code and best practices and focus more about actually shipping things.
- sixothree 3y agoIt matters 17 years later if you’re still in the same code base.
- maccard 3y agoBest practices evolve. This code base predates modern smart pointers, and from experience bit fields were a requirement on some of those... tougher platforms.
- sixothree 3y agoIt was a little bit tongue in cheek. But I'm currently in a code base that is almost exactly 10 years old. And of course all of the developers have personally grown in that time. But some of the practices were dependent on the technology choices available at the time.
- ranting-moth 3y agoHow did this negatively affect the project?
- slig 3y agoDon't do that unless you want a random commenter shitting on the code you wrote 20 years ago when it finally leaks it.
- secondcoming 3y agoNothing wrong with bitfields.
- rvz 3y agoWho cares? Clearly the gamers, reviewers, etc don't care. Only pontificating armchair field marshals giving their take of 'anti-patterns' in game engines built decades ago. That game made millions. Went on to release multiple sequels after the first and still made millions. Is your game engine making millions?
- torginus 3y agoIt's weird to criticize all this stuff considering modern dev companies often have teams like 'billing' that have more people in them than the dozen or so developers who have built the entire video game (plus editor) from the ground up.
- badsectoracula 3y agoPretty much everything you mentioned is also in Unreal Engine and they affected it so much that companies left and right throw away their own engines to switch to it. My favorite part of UE5 is that its "base of all classes" object class (UObject) has its own base object class (UObjectBase). Actually not just UE, but almost everything you mentioned was in every single engine i worked on (to be clear these were all engines that started long before i worked on them and designed by completely different people). With a single exception they were all used to release well received AAA games. None of that stuff actually matter at all in practice.