Planning my code?

[Yardood]

Can someone please recommend me on a right way of working with codes?
how should i plan it?
how should i arrange it?
every time i start a project i find myself later struggling with the difficulties of an unplanned project.

how do YOU do it?

[Schol-R-LEA]

Ah, a good question, and one I am actually glad to see here. It shows some thought beyond the usual questions here.

However, I should caution you that thater are a lot of ways to approach this issue, and which is going to work for you will depemnd on both your own temperment, your experience, the scope and nature of the project, and who well established the conventional solutions to the problem(s) are. You generally will approach a small project different from a larger one - or rather, you generally want to do as much as you can to break larger ones down into smaller ones, then apply the design principles to the individual parts.

One thing I will say is that your approach will evolve over time, as you become more fluent in the programming languages and techniques. Just as when you arew learning a spoken language, and often have to rely on phrasebooks and dictionaries to get your through until you start to actually grasp the language, so too will you need to work a lot with references and tutorials at first. The difference is that this is a wide-open field, and one that changes rapidly, so chances are there will always be things that will send you looking for reference material no matter how skilled you become.

Not knowing what you're skill level is, let's start with the simplest suggestions first:

1. Try to get familiar with as many of the common data structures, algorithms, and design patterns as you can ahead of time, or at least know where you can look them up. Watch for places where you can apply them in your programs when you think they would be useful.

2. Consider the kinds of things - data, objects, whatever you what to call them - that you want to act upon. Define those, at least informally, before you start thinking about what to do with them and how to do it.

3. If you have a lot of objects, or their related to each other in complicated ways, try drawing a UML diagram of the objects and their relationships.

4. If the things are complex or have special properties, try to come up with rules (which will become your library functions or instance methods) about what can be done with those things, and figure out what you need to know in order to do them, independent of the rest of the program.

5. Try to come up with a high-level, over all picture of what the program is supposed to do, and set each logical group of actions out as separate piece. Try to figure out how to keep each piece as independent of the others as you can, to make it easier to reason about them separately.

6. For each piece, work out how you would solve the problem by hand, on a piece of paper. Go step by step, as specific as you can, and write down the exact steps you need to take to solve the problem. This may not be the same solution you end up using, but it will at least give you a starting point. Do not think about the other parts too much, except in the places where one part needs to communicate with another (the interfaces).

7. Try writing out the process in an informal pseudo-code, something that resembles program code but isn't as strict. If you are a more visual learner, you can draw a flowchart or other kind of diagram to describe it as well.

These are just some starting points; there are plenty more things I could add, but I'll let some of the others have their say first.

[David_50]

All programmers work in pseudo code in their heads, with loosely defined objects and containers, until they decide on the flow, steps. Final steps in this process are minimalizing the processing, while retaining clarity of what is happening.

For instance, in designing a sort, one might first read N items into an in memory tournament table sort of tree, then start writing the first max length sorted string onto the first temporary file, the go to a second temporary file, using some concept that tries to keep the number of files and the number of sorted substrings on each file equal, so N first pass temporary files can write N second pass temporary files, and then it must merge N files into the final output. Determining the tournament size is one problem. Dealing with 137 substrings on 8 files efficiently might take some special logic to deal with the not square number. It might be more passes, as you can only open N files at once to merge, unless you use mmap() in place of fd. (With mmap() you can write all intermediate data to one file and then mmap() it to the address space, and merge any number of strings simultaneously in virtual memory.) You might open one extra output file and keep the files open, so when you cannot open another file, you know that dimension and can merge what you have onto the reserved output fd. You might dynamically react to the limit, so if you have 357 temporary files but can only open 251 (for a 256 fd limit), it writes 251 files on the next pass, even if they have multiple strings to merge, forcing another pass. Finally, you want the final merge to have N files of equal number of strings, sorted. Merging small to large is wasteful. Also, merging fixed size has seek/random access advantages over sorting variable length, where you need an intermediate array of pointers and lengths, as opposed to seeing the data as an array on N byte blocks. Merging two streams to one, in a tree of merges, helps organize the merges, and they can arrange for short to merge to almost as short.

[David W]

An other way to learn is by observing the coding steps ... and code ... of master coders.

Then trying to implement what you have learned to solve similar problems.

Some prof's will, at first,
outline the code-developement/code-testing steps ... step by step.

Then you can very easily 'see' how the solution process is progressing,
as you code/test each next part,
to be added in ... in the develop/test process.

Then you can use a similar process to layout and build/test your own, top-down designed ... and built, bottom up solutions.

I would recommed a text like this one, by a seasoned teacher and master coder:

http://plantation-productions.com/Webster/www.writegreatcode.com/index.html

[Yardood]

WOW i wasn't expecting so much investment in the comments.
thank you guys, I think I like this place!
getting to work...