View Poll Results: Functions first, or code first?

Voters
18. You may not vote on this poll
  • Functions first!

    15 83.33%
  • Code first!

    3 16.67%

Poll!

This is a discussion on Poll! within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally posted by funkydude9 Hmm. It's hard (for me, at least) to write functions & classes if I don't know ...

  1. #16
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    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.
    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.

    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.
    Last edited by Cat; 07-18-2003 at 05:47 PM.

  2. #17
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Glad someone else has an OOD rant too.
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How do you create a Poll?
    By cpjust in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 01-30-2009, 10:35 PM
  2. Poll - Terrorism & Torture
    By Kybo_Ren in forum A Brief History of Cprogramming.com
    Replies: 38
    Last Post: 12-04-2006, 01:08 PM
  3. Hungarian Notation POLL
    By maxhavoc in forum A Brief History of Cprogramming.com
    Replies: 13
    Last Post: 06-21-2004, 10:52 AM
  4. Today on Cprogramming....When Polls go bad?
    By incognito in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 01-25-2002, 12:41 PM
  5. Poll this Poll that
    By ski6ski in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 09-28-2001, 04:19 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21