Hi there, I have a favor ask from the ppl who are really into C++. I have a problem. I don''t know how to structure a program. All I know about programming I taught me myself and to get to the point, I have the confidence to practically do everything that I can imagine if I get myself into it and given a certain amount of time BUT, I fail at structuring my ideas into a good design. The OO view easily lets me create my classes I need, their hierarchy and their interfaces. But compile time design doesn''t have anything in common with runtime design. To specifiy my problems more clearer I''ll give you some thoughts: 1. When will objects be created ? (When is it fitting, stack ?) 2. By whom ? (objects and especially threads) 3. Who takes care of them ? (Getting rid of them and such) All of these very abstract question can be answered quite easily with ''The way I want it''. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don''t have any reassurance of what I''m doing. It''s killing me. Do you have any advice for me like a page that explaines patterns like MVC and such or any other hint, for example joining some project ? Any comment would be appreciated big time( even if you want me to go to a psycho doc ) Lorenz

quote:Original post by sprinter_trueno
All of these very abstract question can be answered quite easily with 'The way I want it'. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don't have any reassurance of what I'm doing. It's killing me.

Most software stinks!

[edit]
To answer your question, maybe this online book helps a little:
Bringing Design to Software
[/edit]


[edited by - darookie on March 5, 2003 7:10:36 AM]

quote:Original post by sprinter_trueno
I have a favor ask from the ppl who are really into C++. I have a problem. I don''t know how to structure a program.

I am following three principles:

1. Start small
2. Move in small steps
3. Keep it simple

As a result, I start with code that already is structured, (anyone can structure 100 lines of code). And as I keep adding code, I only have to ensure that I don''t ruin the current structure, which also is simple, since I add only small amounts of code. When things start look really ugly, I stop coding and do a little cleanup.

Thanks for the advice but that is actually the path I do not want to walk anymore.

See, if I do some coding even if it is in small steps i end up mopping the floor with what i''ve written. If I want to write an algorithm for whatever I totally agree with you. I''m not that kind of person that sits down over a math book and works out every detail. Won''t work in the beginning but a little bit of ''cleaning up'' will do the job after a while. Fine.

But now imagine just a small program (GUI, File I/O, some algorithms) and you start to have 15 or 20 classes, a little
''CleanUp'' now and then will lead to compromises and each compromise you accept will make you accept another one later on.
Until you get so stuck with recoding the damned thing 24/7.

Don''t get me wrong, coding in small steps is a must for everybody but coding without a design is suicide.
When I started programming i was so fascinated that what i coded really came to life and made me go on learning more. With time you understand how the software works that we use so casually everyday and you start to aim for that. But since this is a little bit more complicated than just hacking in a few lines you wind up having written more than a hundred pages of code and not knowing anymore why it really works. And the ''WHY'' is what I cannot stand anymore. That''s why I liked programming so much in the beginning. I was able to grasp it in whole.

Relying on a design, that I didn''t need back then, would provide me with the understanding I lack so much. Learning how to structure my personal requirements towards the piece of art I wanna create is the only way that I would be able to write good software.

quote:Original post by sprinter_trueno
When I started programming i was so fascinated that what i coded really came to life and made me go on learning more. With time you understand how the software works that we use so casually everyday and you start to aim for that. But since this is a little bit more complicated than just hacking in a few lines you wind up having written more than a hundred pages of code and not knowing anymore why it really works. And the ''WHY'' is what I cannot stand anymore. That''s why I liked programming so much in the beginning. I was able to grasp it in whole.

You are exactly describing my own experience. I also remeber how fascinated I was about my first programs doing trivial things like displaying a single character in the right place or something like that. And then (actually there was a lot of time between) I learned all those modern programming methods, and as a result I also was unable to understand my own code .

Then I thought - WTF, how come everything was so simple back in the good old days, and now everything''s so complex. So I returned to my original coding style with no OOP, no design, no planning, AND EVERYTHING IS SIMPLE AGAIN!!!1!!1!!

quote:Original post by Advanced Bug
And then (actually there was a lot of time between) I learned all those modern programming methods, and as a result I also was unable to understand my own code .

Which implies that you actually didn't 'learn' them

quote:
So I returned to my original coding style with no OOP, no design, no planning, AND EVERYTHING IS SIMPLE AGAIN!!!1!!1!!

At least for you, but remember that this only works if you and
only you write and need to understand the code.
Try to maintain some 5 year old piece of software, that you wrote
this way and never touched since. If you still understand everything (after some hours of looking through it that is),
then this 'non-style' of programming might be alright for you.

Just out of curiosity:
May I ask how big your current project is (e.g. how many lines of code) and how many time you usually spend on it?


[edited by - darookie on March 5, 2003 9:27:22 AM]

quote:Original post by darookie
Just out of curiosity:
May I ask how big your current project is (e.g. how many lines of code) and how many time you usually spend on it?

Current project: 500 lines (I started it in Monday)
Biggest non-OOP project: 6000 lines (fully functional space shooter)
Biggest OOP project: 30000 lines (simple IDE for GCC compiler, most code was OO wrappers for Windows)

On the other hand, there are examples of big programs written in similar style - like DOOM or QUAKE.

quote:Original post by Advanced Bug
On the other hand, there are examples of big programs written in similar style - like DOOM or QUAKE.

Quake is a bad example - it makes use of OOP, it's
just written in C so you won't find the 'class' keyword anywhere
Inheritance and other features are implemented using function pointers and structs, but I agree that these are rather big
pieces of software written in an awful style.
However, those are again written by only one programmer for the most part.

I asked you about the code size, because I started with 'planning', 'designing' and 'OOP' after my first big projects hit an overall size of about 200.000 lines of code
(it was a DOS SciFi tycoon-style game) and I wasn't able to figure out how the damn thing worked after a 'creative pause' of about three months.

Since it ran very unstable and couldn't find out why, I decided
to rewrite it from scratch applying OOD.
I successfully finished it (it ended up being about 300K lines of code (excluding comments!) and worked like charm.
I spend almost three years on it, spending about 10 hours a week
coding on average (so I had to look up my docs every few weeks
when I touched some older parts).

I wouldn't have managed it without switching from my chaotic
'let's try it this way - wow, it works'-style to a more
formal and goal oriented approach, so I was wondering how you
manage to create and maintain large programs whithout any
design...

Cheers,
Pat





[edited by - darookie on March 5, 2003 10:53:01 AM]

quote:
It is also known as Analysis Paralysis.

Wow ! There is even a word for it . It really hits the spot.

Thanks alot for the advice (to all people who commented). I will look up everything and try to keep on going.

C ya