How do you design your programs?

I want to know how you design your programs. Like the code style you use, and how you keep it structured. Do you keep a notebook with you to jot down ideas?

Personally I write my code like this
1
2
3
4
5
int myfunc()
{
    // Some code
    return 0;
}


I think one liners need to be on one line for space reasons
if(player.collided()) {return true;}

I will never do this:
1
2
3
4
int myfunc(){
    // Some code here
    return 0;
}


I use getters and setters, and I quickly realized writing an RPG engine is very hard to write without the use of dynamic memory, so I learned how to use vectors as a dynamic array.

I don't plan anything on paper, I just make stuff up on spot. If I have problems with my program logic, I look how things are handled in other situations, and try to apply them to mine.

I do jot down ideas because my technology teacher told me to do so when engineering so I applied those skills to programming. I am starting to adopt to-do lists. I hope you guys can share with me what you do.
It is code style question. There is no definite answer to that. Choose one which suit you and follow it. If you will ever work in programming area, you will have to adhere coding style which used in your company.

Here is link with basic info:
http://en.wikipedia.org/wiki/Programming_style

I personaly prefer slightly modified K&R style:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
namespace x
{
//No ident
class Foo
{
  public: //Half ident
    Foo() //Full ident
    { //Functions, classes, namespaces have opening brace on new line. 
        if (true) { //ifs, loops and other use 1TB style
            bar();
        } else {
            baz();
        }
    }
}; //Foo

} //namespace X 

One-liners are used only if they don't have else branch and is trivial (usually alters control flow)
if (x) break;
Empty loop body should still have its own line:
1
2
for (char* x = ptr; *x != '\0'; ++x)
    ;


I don't plan anything on paper, I just make stuff up on spot. If I have problems with my program logic, I look how things are handled in other situations, and try to apply them to mine.
Probably you have already run into code duplication issue and dependency hell.
It is better to design your program before you will start to write code. You will start to understand that only after you will drop your project because of infinitily increased complexivity. That is normal. Nobody understands why some good practice rules were invented unntil he reinvents them after running into serious problems because of negligence of said rules.
Last edited on

It is better to design your program before you will start to write code.


While it is good to think about *high-level* design up-front before starting coding, this is generally not a good advice to spend too much time on it. In all except trivial cases, you don't have real understanding of the problem before you start coding it. Therefore, doing too much on-paper design is just wasting time - you'll get that wrong anyway.

I usually think of high-level design / algorithms / interfaces (but not in every detail), then I start coding the most critical core part of the program as a proof of concept (e.g. no user interface, no tests, no comments, nothing that would waste my time if it turns out I got the problem wrong). And when coding I usually do it bottom-up, not top-down. I have never seen top-down working anywhere (the main problem with top-down is you don't have anything working until you really finish; with bottom up I can start from a tiny 10-LOC function that already does something).

Then I refactor the code and make it tidier and better structured, add comments, tests, simplify the code, sometimes optimize critical parts if needed, etc. Then I add more functionality the same way, refactor, and so on, until I finish. This is an iterative process and works very well with any size of the project.
It is good advice to spend more time on design than on coding if you want to do more than coding in future. It may not seem productive until you've gained experience, and isn't necessary for small, one-off, underspecified jobs, but if you don't try, you're not going to learn.

Diving into the code before you're sure what you're doing means you run a high chance of making components that work, but are useless for the task at hand (or, worse, can be tweaked to become useful)

Of course proof-of-concert skeleton code is important too, it would be much harder for me to get the budget for even a thousand hours if all I had to show were a bunch of UML diagrams. I always get some numbers first. Oscilloscope screenshots worked great, too.

It is good advice to spend more time on design than on coding if you want to do more than coding in future


This is nice theory that is behind a waterfall process of development. Guys doing waterfall often use fancy tools from Rational and create lots of nice-looking UML diagrams. And you know what? It almost never works. I mean, if you have $40 million dollars and 10 years to spend on a project that could be done by 3 engineers in a year, go waterfall. In all other cases, go agile - don't ever touch any UML designer, prototype fast, refactor early and often.

Of course agile does not exclude thinking or even designing small parts of the system. But you don't need UML or formal "design" for this. Just talking to your mates and shortly describing approaches is usually enough, because you are supposed to be working on *small things*. Then go prototype, and eventually fix later.

The biggest problem with spending too much upfront effort on design is that once you finish your design phase, most of your assumptions are obsolete. And some of them you even don't have really a f***ng chance to get right the first time. Another problem is "feature-creep" - you design too many features, you end up with too many abstractions and too many extension points, which then turn out to be unneeded. In C++, this leads often to creating pure virtual base class or template and then having just one implementation / template instantiation. Pure nonsense.
Probably you have already run into code duplication issue and dependency hell.


Actually no, I don't. The only project I dropped that I don't work on from time to time is my project Kyden, where it was good but I over designed it on paper and when I got a tech demo down, it got overly complicated and I got the idea to make a RPG, which I'm working on now.
my style coincides with Aldman ANSI style out of shear coincidence. barely remember how I coded before.

I design my programs in my head. But I know different models of design, waterfall, spiral, iterative. I been doing it partially as a mental exercise and also because its what Ive been doing since from when I 1st started coding. Also, Sometimes you can learn a lot from reading other peoples code. Like how NOT to code if you want people to understand you. Right now I just plan what Im gonna do in my head, then I code reasonably and comment as I go, because commenting, like proving can lead you exactly the result you want with not too much effort. The downside to that method of building programs, is sometimes you might want to change the upper level or most high level of the interface. which is not good (counter-productive) if you are working top-down.
Last edited on
Topic archived. No new replies allowed.