Well, writing code is not even nearly the first thing you should be doing when writing a program. Step 1 is planning. You need to completely brainstorm about how your classes will interact. You need to think about all the objects you will need and create a list of classes. For each class, you need to think of every possible thing you will need to do on that object. I find it helps to draw lots of pictures about how things will interact. In at least one professional company I know of, programmers actually *roleplay* the interactions between their classes. E.g. if I am an object of class CDisplay and you are class CGame, you might tell me to draw myself, at which time I tell any other objects to do things, and then tell CGame I am returning to it.Quote:
Originally posted by funkydude9
Hmm. It's hard (for me, at least) to write functions & classes if I don't know how I'm going to use them or write them. I make them as I go along, that way I have a better understanding of how I'm going to use them. Not sure why that would be a problem even when writing lot's of code. :confused:
The goal is to create a complete and total interface first. For example, in a game, I would have a CMap class that would handle the map. I would brainstorm all the things the map should do -- constructors, file I/O, drawing the map, displaying the map, etc. I don't care yet about the details of how each task is accomplished, I don't care about private data members, I only care about every single aspect of the public interface.
After that, I'd start implementing the classes one at a time, starting first with at least some form of output (for error/debug messages) and making sure all the code compiles and runs with each change. I'd test the classes one at a time as I create them.
Writing code without being able to see the big picture is a death trap, especially when working in teams. Often, work will be divided up, so you have a set of classes that you are required to implement. Even when working alone, time spent carefully considering the problem pays off in the end -- code is much easier to debug, bugs are easier to fix, and so on.
I remember one time, the last time I started writing code without totally thinking things through first. It was an editor for a type of database. I wrote the entire thing and then tried to add a feature. Due to how the database worked, certain sequences of records had to be terminated with a null record. Originally I offered no way to add null records when the user omitted the null record. Later I added a feature: when saving, it would add null records as needed. Simple, no? But thanks to not planning this through at all, and not even thinking about issues, it ended up that adding a record when in the middle of saving would cause some records to be duplicated and others lost. During my tests, it never was apparent, but my users found this out in less than a day. I ended up needing to rewrite 75% of the code in the class; the code was so terrible in most parts I didn't even try to track down the many bugs this one simple change had introduced, and instead I started from near scratch.
I guess the moral is, plan ahead. Rather than building an interface on the fly as you think of things, come up with the interface before you even touch the implementation.
I remember also a series of versions of a program I did, before I really became good at the language. Each worked, but was not written at all for code reuse -- interface and implementation were tied together very strongly. The display of the data was linked so strongly to the data that simple user interface changes became difficult to make. The program went through three major revisions (I might do a 4th someday) and the funny thing about this was there was not a single line of code from v1 that made it into v2, or v2 that made it into v3. Most of the changes were user interface improvements. My code was so poorly designed it was not possible to salvage ANY parts.
Nowadays, I wouldn't even consider writing code that poorly.