Do you typically write your functions first, then code them, or write your major code first, then implement it into functions?
I always find it easier to write all my code first, then place them in functions...
Printable View
Do you typically write your functions first, then code them, or write your major code first, then implement it into functions?
I always find it easier to write all my code first, then place them in functions...
Always top down. Map out the classes I need, map out the public interfaces for each class, then implement.
Working the other way (writing the interface as the code progresses) is a terrible habit to be in.
Moved to GD
>>> always find it easier to write all my code first, then place them in functions...
Wait until you start to write 500,000 line programs, I think maybe you'll have learnt by then!
Classes & Interfaces first, code later. In larger programs, there is no way to write code first. Not if you want to succeed.
If you are developing a large program, it will be easier to write classes first!
I never wrote a VERY large program, but whenever I have a large assignment I write classes first( or functions ) first.
I get a basic idea of the classes and functions I need and start coding them, and then if I find that I need something else, I add it. Ya know, sometimes there are things that you just don't think of in advance.
I take care of all classes and functions and such before i write any code. It helps to write algorithms.
> I always find it easier to write all my code first, then place them in functions...
Are you insane?
>> Wait until you start to write 500,000 line programs, I think maybe you'll have learnt by then!
You put it too delicately Adrian.
Anyone who would write "code first" for something that large should be dragged out into the street and shot (which is precisely what their compiler will do to them).
you'd be surprised how many dinosaurs of the industry actually code that way. Zero structure, zero thought behind the architecture. It's like pulling teeth to get them to put thought into OO design. It's even worse to try to convince managers that it's to their benefit to take time to restructure spaghetti code.
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:
>> Zero structure, zero thought behind the architecture.
Code like that should seriously be deleted and started over.
funkydude, the thing about OO design is that its extensible, and easy to maintain. No single piece (at least in theory) is too hard to digest, and has clearly defined dependencies. In a major piece of software, deisgn must be put in to determine exactly what abstractions are needed, how they will be used, and how they are expeced to behave. Granted, you'll run into unforseen requirements or conditions, but if you minimize those, your coding is a lot more efficient. Also, programmers brought in to maintain or extend the system can easily do so by only touching a small portion of code. They only need to know how things behave, not how they are implemented. Failure to design beforehand will lead to a much poorer overall structure.
And that concluded my OOD rant for now. :cool:
I think that people who said that writting code first is easier were talking about small and simple programs, maybe because they haven't written large programs, or complicated ones, where it's impossible to write the whole program at once!
I just write empty functions first, just to make sure that my framework is valid. Then I begin filling them with code in the order that they will be executed.
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.
Glad someone else has an OOD rant too. :)