Hi all! After many posts "against" C++ (and OOP, and design patterns), and after the very successful collaborative engine design experiment, I think it's the time for a new, more positive post.
In the end we're still tied to use C++ in our day to day jobs (well, if you do realtime rendering at least...) so we have to survive that...
Also I've always wanted to write some sort of coding "flashcards", something visual (also to help code reviews), of the form "if you see something like this, then you should think about that", so why not trying to do that, and also to leverage on the experience of you guys to make it super-awesome?
Here it comes... The collaborative visual coding guidelines experiment!
I will keep this etherpad around for a while. I hope it will see the same (or better!) participation of the last etherpad experiment I proposed. When the document grows "stable", I'll publish the results on the blog.
Enjoy!
3 comments:
Is this meant for C++ games programmer? Otherwise I would not understand why it is a good idea to avoid boost. The overall quality (with a few exception) of those libraries is great.
I guess this is meant for game engine development. As a rule of thumb, design patterns are often cost effective ways to raise the scalability anda reusability of software. Game engine architecture is quite different from regular applications, as such most design patterns don't make sense (except perhaps the Singleton, Composite or perhaps the Flyweight).
Yep, it's about games
Post a Comment