I must be doing something wrong (slow development)

Started by
29 comments, last by slayemin 11 years, 10 months ago
What I wonder is whether to implement good design under C++ one absolutely has to use templates, polymorphism etc or is using classes, at most perhaps inheritance, sufficient to design a big program?
Advertisement
I think you can create large programs even with only some classes and inheritance.
It is more a question of the overall structure.
You can even do object oriented programming in C. But then you are forced to manage the encapsulation of methods and attributes by yourself and this allows you to ignore the rules at will.
C++ helps because of the language constructs that helps you in staying object oriented all the time.
When you think of it you can manage very large programs in plain old C. Look at Linux.
I read a study somewhere that at a large software company, the most productive programmer was more than 60 times as efficient than the least productive professional programmer. I find this very plausible.

When you think of it you can manage very large programs in plain old C. Look at Linux.

Yup, but I don't think coding in C helps speeding up production...

I'm a C coder, and I do think (based on some observation on the forums) that C is feasible (or even a good tool) for rapid prototyping (if we don't use engines of course). But for anything serious and releasable, well, it's not a fast tool. I love C so much I f.ck it, but I started to seriously think about switching to another language. Whit which I can program as fas as with C, but the outcome won't be some swamp where the project just gets stuck and in the end, I just can't make anything medium sized.

I read a study somewhere that at a large software company, the most productive programmer was more than 60 times as efficient than the least productive professional programmer. I find this very plausible.

This may be.
Another interesting measure. Even a good software engineer does not produce more than 25-50 lines of code per day, that is tested and works and is robust. This means has proper error handling and reactions.
With small systems around 2k-5k LOC this maybe a bit more. But the more complex the software grows the more you come to the 25 lines per day.
The whole reason we have higher level languages is because they allow greater productivity. I'm not necessarily suggesting that you switch to java or .net but maybe you can find a way to reuse more code or even create constructs that increase your productivity??
In addition to the great advice that has been given so far:


Learn what capabilities your tools offer, and learn to make use of any functionality that can help you.

Don't screw around with print (or equivalent) statements trying to track errors if there is a fully-featured debugger that could do the job better. Don't guess about where to optimize an overly slow program if you can use a profiler to get real data. Don't type out the full text of a lengthy variable or function name if a code-completion feature can do it for you.

Obviously you don't want to sink your time into learning the ins and outs of every little option your tools provide, but in the long run it can be well worth spending some time learning how to properly use any functionality that can benefit you.

- Jason Astle-Adams

@M6dEEp:
This is what they are created for. But because of the complexity of the software that is needed all around to use these languages, different interpretation of standards, in case of JAVA and .NET, changing the language and all that things influences the productivity as well.
This is why I am trying to use as less features as possible from a language. This means not, not using them at all. But think about if its really needed.
The biggest mistakes I committed myself were (and probably still do :D ):

1 - Trying to go too high with over complex games I had not enough experience to engineer and program;

2 - Did not read a sigle book to the end, not Game Coding Complete, not Programming Game AI by Example, not Introduction to Game Development, I usually skipped lots of topics I, mistakenly, judged delayable...

3 - Followed simplistic internet tutorials thinking they'd teach me all the necessary stuff I'd need to know before creating games; They are great for kickstarting, but you can't follow a tutorial to set up your environment, other to code your classes, to compile your program and everything in between. You'll end up having problems while using CMake to build Box2D, for example, and there'll be no decent up-to-date tutorial on how to build and link Box2D 2.2.1 in a Code::Blocks 10.05 SDL 2.1 project... There'll be a time you'll want to do something that none of those tutorials covered, and then you'll have to go back to the basics, and I mean basics!... (I'm repeating myself, can't help it)

4 - Never really planning, engineering, modeling, my app. I simply wanted to ragetype on my keyboard and see the game pop out in the sequence. It worked for the "tetris clone", for the "pac man clone", and other simple games. But when the game's complexity goes up linearly, if you do not plan your classes somehow (anyhow), your coding dificulty will increase exponentially.
I always made a subpar modeling of my apps, some "mental model", but nothing really definite, how we learn when studying OO.

5 - Only considering one language (be it java, C++, C#, Obj-C, Lua, Love2D, Ruby), always ask yourself if you have chosen the right language.

This topic is closed to new replies.

Advertisement