OBJECT ORIENTED VS C STYLE for small projects

When doing small projects (a day or less) how many of you don't take the time to create the data structurs, rather you just throw everything into functions? I am one of those people that do that, although it shouldn't really take all that much time and excercise in the OO paradigm seems like a good thing.

No.

I always find that a stitch in time saves 9.

ill probably reconsider my own tactics

It depends on how do you define a small project...
I think that you can always know what to use...

I'm making a Recipe catalog program in C++, and the only thing close to OOP in it is a linked list.

I always go straight-OOP, even on small projects.

What poly? Are you serious? Oh come on, someone with the name Polymorphic Object Oriented Programming/Programmer uses object oriented programming? Come on! That's ludacris! I've never heard of such a silly idea in my life! j/k man, im a dork.

Well I already defined small project, something you can do in a day. Now, that's somewhat ambiguous, because a lot of the things you do in a day can still be huge. I'm just trying to compare it to a system that might take a month or two to develop, in that case object oriented is the way to go. Right now Im' doing an opengl animation of a gold atom, no object oriented programming, although it would be appropriate (Particle ADT class, Proton, Neutron, Electron all derive from that) but instead I'm just throwing crap into functions because this is not going to get to be a complicated system (objects wouldn't really need to react with each other). The total estimated time for this project is 3 hours (I did all the winapi code with some buttons and menus and crap, which takes a long time for me cuz i suck @ winapi).

I usually use OOP for projects > 2 days long. Under 2 days, I usually get done faster if I don't have to design the classes and junk, over two days, it saves me a LOT of time to use classes. I L-O-V-E OOP.

I usually use OOP for projects > 2 days long. Under 2 days, I usually get done faster if I don't have to design the classes and junk, over two days, it saves me a LOT of time to use classes. I L-O-V-E OOP.

my attitude exactly; it makes things easier in the long run but in the shortrun stuff's goin into functions just for a quick cheap coder high

The key is this: Do you ever think you'll need to revisit the task on hand? Will you ever need to modify or expand this code? If so, then you want to design so it's easily changable. The key to design is to make your code readable and understandable so you never have to question what you were doing.

I've looked at code I've written in the past and wondered "What the hell was I doing here?". It's best to avoid this by clearly outlining what the job you're doing is, and if need be, what reason you chose for doing it that way.

I'd say design methodology isn't that much a big deal so long as your code is understandable.

Quzah.

I try to plan my projects out as well as I can, but sometimes I challenge myself. See how quickly I can come up with a solution to a problem.

For instance, the other night I tested myself to see how quickly I could come up with a program which would convert html tags to upper or lower case, leaving attributes, javascript and other junk alone.

The source is MESSY, unoptimized, and in most cases hard to undertstand. But the thing is, it works!

Afterall, isn't your objective to solve the problem?

I really don't believe in "small projects". Anything you do today may be useful tomorrow. Initially when I start a project, big or small, I think about the services and tools it will need to come out modular. I build these first, test them, and then code the actual program. In fact, my latest project, encapsulating Windows, has taken several months of coding, and the whole time I didn't write a single program. Imagine the anticipation! The entire library now consists of about 20,000 lines of code, though it has been rewritten several times over, so a lot of coding has gone into it. The point is, "the framework should come before the program".

Here's a good exercise, too, by the way:

Write a program as quickly as you can, making no effort to be neat or tidy. Just get it to run without errors. Now delete the project and write the very same program, again, as fast as you can. Repeat as many times as you can stand.

This exercise is useful because it teaches you to have the will to rewrite anything, which is very important, and also keeps you up to speed and sharp, of course. It's interesting too seeing how the program becomes more and more refined each pass.

- Cheers

Afterall, isn't your objective to solve the problem?

That is an objective, otherwise programming would be useless.

But if you make it messy, then you cannot reuse the code later on. I did that a lot with BASIC and the result was having to write each new program completely from scratch (which is why I never finished anything with BASIC).

Having modular programs is good because you can later take any code you have that might work and reuse it saving you time.

This exercise is useful because it teaches you to have the will to rewrite anything, which is very important, and also keeps you up to speed and sharp, of course. It's interesting too seeing how the program becomes more and more refined each pass.

- Cheers

Sebastiani, don't stop there! Keep the suggestions going!!! I like reading about things like that other (better) coders do in order to enhance their skills.

You're a goober.

The best exercise is just programming constantly. I program at work, program when I get home, and whenever I'm not programming, I'm thinking about it. I think as long as you get a solid 4-12 hours a day at it, you're bound to improve considerably, which is of course, just like anything else. One of my favorite past-times is creating libraries of mechanisms. A mechanism in this sense, is an atomic operation that is often reused. Start with the smallest mechanisms and then build bigger mechanisms with these. Here's an example:

How often have you done this?:

Code:

int Foo(int new_value){
int old_value = value;
value = new_value;
return old_value;
}

This could be considered a mechanism, and it is a very common operation. Templated we get:

Code:

template <typename number>
number cycle(number& value, number new_value){
 number old_value = value;
 value = new_value;
 return old_value;
}

Now we can rewrite Foo() like this:

Code:

int Foo(int new_value){
 return cycle(value, new_value);
}

Now consider this operation:

Code:

void Swap(double a, double b){
 double temp = a;
 a = b;
 b = temp;
}

Of course, the STL has the swap() function, but bear with me. We can reuse the cycle() mechanism since it does half of a swap:

Code:

template <typename number>
void swap(number& a, number& b){
 b = cycle(a, b);
}

Finally, let's consider where you need to an arrays elements over to place a value somewhere in the middle, much like a linked list. Not a very efficient operation, but then sometimes it must be done. Here's a simple solution using the swap mechanism:

Code:

template <typename type>
type shift_back(type array[], int start, int stop, type io = 0){
 int iter = start;
  while(iter < stop){
   swap(array[iter++], io);
  }
 return io;
}


template <typename type>
type shift_back(type array[], int length, type io = 0){
 return shift_back(array, 0, length, io);
}




template <typename type>
type shift_forward(type array[], int start, int stop, type io = 0){
 int iter = stop;
  while(--iter >= start){
   swap(array[iter], io);
  }
 return io;
}


template <typename type>
type shift_forward(type array[], int length, type io = 0){
 return shift_forward(array, 0, length, io);
}

And now let's put it "practical" to use.

Code:

int main(int argc, char *argv[])
{
  char message[81] = {0}, c = ' ';

  strncpy(message,
  "News Flash :: News Flash :: News Flash :: News Flash :: News Flash :: News Flash :: News Flash ::", 80);

       while( !kbhit() )
     {
       printf("\n\n\n\n\n\n\n%s", message);
       c = shift_forward(message, 80, c);
       Sleep(100);
       clrscr();
     }

  getch();

  c = ' ';

       while( !kbhit() )
     {
       printf("\n\n\n\n\n\n\n%s", message);
       c = shift_back(message, 20, 60, c);
       Sleep(100);
       clrscr();
     }
  return 0;
}

So mechanisms are the nuts and bolts of a program. The more you capture, the more generic and effortless programming will be for you.

I hope that was helpful to you. Happy coding.