5 ms·

Seems as you've picked up on the same thing - "I've worked in the Games industry with age old engines, I currently work in embedded development with a code bas

Seems as you've picked up on the same thing - "I've worked in the Games industry with age old engines, I currently work in embedded development with a code base over 10 years old - I'm fully aware of what "real life" code is like. There is no excuse for not writing well commented code - or even code with well named variables and functions that reduce the need for as much commenting. If you suffer from code like this in your workplace, perhaps actively comment it as you reach an understanding of what it does." Relatively experienced 6 year C++ dev - I mainly mentioned university because things where much stricter - but having an environment with decent code reviews and maintaining a little self discipline goes a long way with the sanity of your co-workers.

sillysaurus3 10y ago
You're a C++ dev, not a gamedev. They use different coding conventions. You'll find a lack of refcounted pointers, for example, whereas university teaches you to use them. 6 years is significant, but it's not a long time. There's much to learn, particularly about the cultural aspects of various segments of the industry. This is excellent code that was produced on a tight timeline.
- Derpdiherp 10y ago
  I was a game dev for 3 of my 6 years. I just got sick of the layoffs after project ends - and my university tuition was in fact games development specific. *Edit - Yes though - by no means do I think I'm some big shot know it all. But I do have strong feelings about readability after having had to deal with code which is awful to grok.
  - sillysaurus3 10y ago
    Fair enough. It's a valid point of view. Sorry you had to deal with layoffs. It's one of the darker aspects of the industry. To clarify, my objection was that we're criticizing this code for superfluous reasons when it's currently a delicate political climate in most game companies to even release code like this in the first place. It's probably best not to imply their reputation should be harmed by their lack of comments, since this can discourage other game companies from releasing their code in a similar manner. I've seen the argument "it might harm our reputation" be used to block endeavors like this.
    - Derpdiherp 10y ago
      I'd argue that a company should be able to take a little criticism - style based ones like mine will likely be ignored, as you mentioned before it's down to the culture of the company - for every function like the one outlined in the OP I'm sure there's countless examples of good style in the code base, engines are huge. I really hope that companies don't view criticism as a negative thing, it's cause for discussion and change which are most certainly positive - I hope some bugs are found and they start to feel the benefit of the community a little.
- shmerl 10y ago
  What's wrong with managed pointers? Rust uses them just fine. C++11 has them natively. Using raw pointers in C++ is rarely really needed.
  - steveklabnik 10y ago
    To be clear, Rust does support refcounted pointers, but they're used very sparingly, and also have the advantage of allowing regular old pointers to their interior while remaining safe, which reduces refcount twiddling.
    - shmerl 10y ago
      I didn't just mean refcounting, but simply managed ones (i.e. "smart" pointers), in contrast to raw pointers which require manual management. Shared pointers (as in ref counting) is just an example of that, so I understood the above comment as implying that game development somehow encourages manual pointers management. May be I just understood the intention wrong, and it didn't mean to exclude other types.
  - sillysaurus3 10y ago
    In gamedev, using raw pointers is necessary. As a rule, game engines do not use refcounted pointers. This is because whenever you decrement a refcount, you're accessing the cache line in which the refcount resides. This results in thrashing the L1 cache, which translates into at least a 10% drop in performance. This is an unacceptable margin for game engines that fight to stay ahead of the competition. More info on performance loss due to cache thrashing: https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf https://lmax-exchange.github.io/disruptor/files/Disruptor-1.... http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html http://mechanical-sympathy.blogspot.com/2011/08/disruptor-20-released.html http://mechanical-sympathy.blogspot.com/2011/08/disruptor-20... And http://mechanical-sympathy.blogspot.com/ http://mechanical-sympathy.blogspot.com/ is great in general. The reason that raw pointer management works in gamedev is because gamedev is closer to crafting than traditional programming. No one will die if a game crashes, and the iteration loop is a tight feedback cycle of code-compile-run code-compile-run. Due to the nature of the entertainment industry, the codebase also loses much of its value within a year of releasing the game, as opposed to traditional software that typically gains value with time, meaning it's more important to get code out the door than to get it right. History is littered with the skeletons of game companies that disregarded this unfortunate truth.

sillysaurus3 10y ago

You're a C++ dev, not a gamedev. They use different coding conventions. You'll find a lack of refcounted pointers, for example, whereas university teaches you to use them. 6 years is significant, but it's not a long time. There's much to learn, particularly about the cultural aspects of various segments of the industry. This is excellent code that was produced on a tight timeline.

Derpdiherp 10y ago
I was a game dev for 3 of my 6 years. I just got sick of the layoffs after project ends - and my university tuition was in fact games development specific. *Edit - Yes though - by no means do I think I'm some big shot know it all. But I do have strong feelings about readability after having had to deal with code which is awful to grok.
- sillysaurus3 10y ago
  Fair enough. It's a valid point of view. Sorry you had to deal with layoffs. It's one of the darker aspects of the industry. To clarify, my objection was that we're criticizing this code for superfluous reasons when it's currently a delicate political climate in most game companies to even release code like this in the first place. It's probably best not to imply their reputation should be harmed by their lack of comments, since this can discourage other game companies from releasing their code in a similar manner. I've seen the argument "it might harm our reputation" be used to block endeavors like this.
  - Derpdiherp 10y ago
    I'd argue that a company should be able to take a little criticism - style based ones like mine will likely be ignored, as you mentioned before it's down to the culture of the company - for every function like the one outlined in the OP I'm sure there's countless examples of good style in the code base, engines are huge. I really hope that companies don't view criticism as a negative thing, it's cause for discussion and change which are most certainly positive - I hope some bugs are found and they start to feel the benefit of the community a little.
shmerl 10y ago
What's wrong with managed pointers? Rust uses them just fine. C++11 has them natively. Using raw pointers in C++ is rarely really needed.
- steveklabnik 10y ago
  To be clear, Rust does support refcounted pointers, but they're used very sparingly, and also have the advantage of allowing regular old pointers to their interior while remaining safe, which reduces refcount twiddling.
  - shmerl 10y ago
    I didn't just mean refcounting, but simply managed ones (i.e. "smart" pointers), in contrast to raw pointers which require manual management. Shared pointers (as in ref counting) is just an example of that, so I understood the above comment as implying that game development somehow encourages manual pointers management. May be I just understood the intention wrong, and it didn't mean to exclude other types.
- sillysaurus3 10y ago
  In gamedev, using raw pointers is necessary. As a rule, game engines do not use refcounted pointers. This is because whenever you decrement a refcount, you're accessing the cache line in which the refcount resides. This results in thrashing the L1 cache, which translates into at least a 10% drop in performance. This is an unacceptable margin for game engines that fight to stay ahead of the competition. More info on performance loss due to cache thrashing: https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf https://lmax-exchange.github.io/disruptor/files/Disruptor-1.... http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html http://mechanical-sympathy.blogspot.com/2011/08/disruptor-20-released.html http://mechanical-sympathy.blogspot.com/2011/08/disruptor-20... And http://mechanical-sympathy.blogspot.com/ http://mechanical-sympathy.blogspot.com/ is great in general. The reason that raw pointer management works in gamedev is because gamedev is closer to crafting than traditional programming. No one will die if a game crashes, and the iteration loop is a tight feedback cycle of code-compile-run code-compile-run. Due to the nature of the entertainment industry, the codebase also loses much of its value within a year of releasing the game, as opposed to traditional software that typically gains value with time, meaning it's more important to get code out the door than to get it right. History is littered with the skeletons of game companies that disregarded this unfortunate truth.