General Question

gorillapaws's avatar

Object-oriented programmers: what is your process when you're physically coding?

Asked by gorillapaws (16293 points ) August 5th, 2011

When you’re writing new code and you’ve got either a mental model or something sketched out on paper, and you’re physically typing the code, you end up constantly referring to things that aren’t yet built.

For example, I might have a model ObjectA that I’m starting the project with, and while writing a method for ObjectA, I know it needs to call a method I haven’t written yet on an instance of ObjectB which is of a class that doesn’t yet exist. Do you immediately stop writing ObjectA’s method, create the file for the ObjectB’s class, and stub in the method declaration? or do you finnish the original method you were working on? Once you’ve finished the method for ObjectA, do you continue writing ObjectA’s methods, or do you jump over to your ObjectB’s file and complete the method you defined?

The whole process is so non-linear and schizophrenic that I sometimes loose my “flow” and my mental compass get’s turned around. In a way, it’s a bit like a depth-first search vs. a breadth-first search problem. Is there a term for this dilemma in the industry that I could use to search for more info? Are there commonly accepted best practices? Are there some good resources that cover this topic out there? Any practical advice from your experiences?

Additionally, you can’t compile the app until your code is roughly complete, so this can force you to complete dependancies that you were intending on working out in the future. This is frustrating because you can’t compile as you go to verify things are working properly.

Observing members: 0 Composing members: 0

6 Answers

LostInParadise's avatar

What language are you coding in? In .net there are interfaces, that I have found to be very useful. I don;t remember whether Java has anything similar. With interfaces you can avoid the need for stubbed code.

I do find myself working on several things at once. One driving concern is to be able to test as I go along. This frequently leads to initial concentration on auxiliary modules.

gorillapaws's avatar

@LostInParadise I’m mostly writing in Objective-C, but I would think the problem is universal to any object oriented language. It’s like the same problem with writing a choose-your-own adventure book, whenever the story branches, do you continue down the rabbit-hole of one story path, or work out each branch, before delving deeper in?

I guess what’s frustrating is that I get a flurry of ideas, and because I’m so prone to loosing my train of thought, I feel obligated to get it all down, lest I forget. Thanks for taking the time to answer.

koanhead's avatar

I always write “documentation” first. I start with a README file which outlines the way I think the code should go. When I find myself referring to functions (I’m mostly a functional programmer, but this should also work in OO) I’ve not yet coded I write them up in the file with a description of what they should do and what calls them, etc. If I don’t do this I will get lost.
Also, when I’m writing code, I write comments first telling me what I meant to do, then code between the comments. About half these comments wind up staying with the finished code as documentation (except that they all change many times during the programming process- the comments at the end are never actually the same as when I started).
When I program I tend to try to work from the “branches” (functions / methods that are called but don’t call other things) inwards toward the “trunk” (i.e. main() or other parts of the code that need to call things) which allows me to test the outer functions thoroughly before calling them from real code.

Zaku's avatar

Hmm, good question!

I think it depends on how complicated the unwritten methods are, and what I feel like doing. I tend to do what’s easiest for me.

Usually, and when the unwritten methods are fairly complex, I tend to make up explanatory method names and use them as if they existed:

Like (not exactly, but since I have no specifics):
pOtherObject.DoAllNeededLogicForWhenXHappens();

If it’s something simple, though, I may just go implement it and come back.

DrBill's avatar

Flowchart to documentation outline to primary code, then finish wih the subroutines

funkdaddy's avatar

I tend to stick with what I’m doing for exactly the “flow” reason you describe.

One thing that’s worked well for me is to keep a list handy that I jot down those little “to-do” items on immediately when they become needed. This can be a text file, a sticky note, or any of the online to-do list managers that are available.

So I’d stick with the object I’m in right now, because that’s fresh in my mind and I have everything mapped out, but jot down the new method name and either key attributes or an example call to that method/function so I can refer to it later. Usually if I know the name, and the key attributes, I can write the rest without referring (mentally) back to the current object.

Once I’m done with what I’m on and wondering what’s next, that list is populated with all the dependencies and I find it helps me move through the project more smoothly as well. Less wasted time looking for the holes that inevitably occur with any process.

Answer this question

Login

or

Join

to answer.

This question is in the General Section. Responses must be helpful and on-topic.

Your answer will be saved while you login or join.

Have a question? Ask Fluther!

What do you know more about?
or
Knowledge Networking @ Fluther