how to approach a problem solving question - then programming it
Hi,
Just wondering if there is a correct way to approach a programming problem.
What I currently do now is:
1. write a bare pseudocode outline of how the program should work
2.(a) start coding according to psuedocode
(b) if you didn't account for a condition - add it in
(c) debug - if error trace program and fix logic
I would like to learn a proper method so that I don't fall into bad habits. Are flowcharts necessary? Is it best to code the whole thing in pen first?
That's not a C related question and maybe it should be moved in the Tech board.
I wouldn't really say that there is a correct or false method, since every person is unique, thus a method suits one perfect, but not another.
Experience will really tell you what's the best method for you, but here, you can hear advices and test them!
Code - functions and small libraries I use
It’s 2014 and I still use printf() for debugging.
"Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson
Step 1 is always the same - define the problem you are trying to solve, collect your design requirements, and come up with a basic list of the features you are considering. Every feature should be assigned "Must do", "Nice to do", or "Will not do". Run these requirements past your stakeholders / interested parties, and be sure you understand their needs. After all, they are the ones who you're writing for. This list is also partially how you will evaluate your final product - did you actually meet the needs you documented?
Next I usually tackle a basic mockup of the UI. Wireframe programs (I use Balsamiq) are good for this, as they get a rough idea of how you might build the interface without too much detail that it's distracting. Run this again by stakeholders - for more challenging things, consider a card sort or other technique to help make the UI best mirror the workflow it's designed to accomplish.
Now, here's where things differ a bit, since I don't generally use C. Usually, I program in an object-oriented methodology, so I would next start sketching what properties and methods my objects would have, and a dependency graph if it's complex. In C, I would start from my highest-level concepts and work my way down towards the details - sometimes I'll use pseudocode, but often I just use placeholder functions (with an empty body) as I decompose the tasks from the most general down towards the specific. I also tend to start by defining my data structure, and then work outwards from there.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
If you are doing C, I would write all the function prototypes first.
If you have learned headers, I would write the header file first.
Once you learn enough, I would try to learn UML or something like that to do the design work in before doing much code.
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
My way is to first, see if I really KNOW the problem, and the algorithm I want to use for it. Several times I just can "smell" there's a slick math or algorithmic answer, to the problem. Especially the case with Project Euler problems, and other on-line problem solving websites.
This may involve sitting down with paper and pen and little bits of STUFF representing the objects in the problem, and working through the problem, by hand, more than once. I want to express the program in a simple and direct way, for my pseudo code.
I've only used flow charts for a couple programs. The more complicated the program however, the more a flow chart starts making sense.
When I start programming, I use the "Top Down" method: put off ALL the details you can and starting with main(), work with one function at a time - using function stubs where blank functions still have no code yet.
Re-compile often, and test for accuracy as well. The worst thing is to have hundreds of lines of code since the last test, and zillions of errors, when you compile or run it.
After I get the overall flow working, I fill in the details, retesting for accuracy and passing compiling, as I go.
So it winds up being a Top Down, and then a Bottom Up approach. Keeping all the display niceties and such out of the way, while I code up the backbone of the logic, makes that first part, MUCH easier.
As mentioned above, step 1 is to make sure you understand the problem statement, to reduce the possibility of unknown issues with the problem statement. Then you select or create some algorithm(s) that should solve the problem. Next work out a design for the program, usually top down, but I often end up going back and forth between bottom up and top down when defining the basic functions I'll need, to determine where it would be best to implement specific parts of the code. In my case, I prefer to implement most of the functions bottom up, since it makes testing of them easier, since I can feed in what would probably be rare sequences in order to confirm the functions are working.
