Depth First vs Breadth First programming and stubbing

Originally I wanted to title this saying TDD instead of stubbing, but really the reason this topic came up is due to chatting with a friend about writing dummy functions to get TDD to pass, which lead to me commenting that sometimes I want to stub something out so I can say "well let's pretend that works" and move on and get the code I'm actively working, on working.

Breadth First Programming Style
This style of programming is writing the highest level (user facing we'll call it) code first, any calls to functions that should do something or get data or whatever should be quickly written as stubs with something to get you moving in your current function. The next step is moving into the first (or last depending on the order you'd like to go) and managing that functionality. If that calls down into nested functions then you follow the same organization, finish all the functions at the n-1 level of your earlier function and go on.

Depth First Programming Style
This style of programming is writing code that always works at each step. If you start writing and you come across a function you need, you simply drop down and implement it, and if that has functions it calls, you do the same. This keeps happening until you've finished everything down to the bottom, when you move up you do the same thing on the next function until you finally reach the top level and move along again.

Mixed Style
I like to work in a Mixed style. When you're working a complicated algorithm on your main thread of work it makes sense to say, well lets assume we get this data correctly and move on and continue working the algorithm, however if it's a relatively easy problem to solve and dropping into the function the function is a bear, it might make more sense to just implement that function first then move back up to your higher level.

TDD Aside
Since I brought it up I should talk a little about TDD. TDD is to me more of a Depth First style of programming. You write up a test, then you implement a high level of it, and yay it passes, then you write another test and drop back down to the function level you were at and "fix it" and keep doing that. I almost would compare this to a Yo-Yo strategy, you start at the top with a test, and throw your Yo-Yo, then when it gets all the way through the pass you start again at the top. You don't move forward until things are as right as you can make them.

How do you work what is your style? What do you think TDD is like? Are there any other programming styles you can think of  in this context?

Ordered Entry of Form Data UX

As a follow up to this post: Stacking Enabled/Disabled States

I am going to show you a working example.



So now when combobox selected index changes it disables and clears all the form fields AFTER textbox1 (so textbox2, and button1)

Additionally you could set up a similar situation for adding data to comboboxes. If you enter in some data and move to the next field, you could call the same thing and have function pointers for the data on the "next" item in the list (so instead of pointing to 2 down you point to 1 down the list).

Good luck and do you have any tips for Ordered Entry of Form data?

Stacking Enabled/Disabled States

I get annoyed when working with forms that require data to be entered in steps, this is usually how the code works.

1. Write a "on changed" event handler for the field.
2. When fired Set all fields below to disabled.
3. Enable only the next field.
4. Repeat.

All I can think about here is DRY (Don't Repeat Yourself) but how can we accomplish it?

I'm thinking you build an ordered list of all the fields, then when an on change event handler fires, it finds where your field is in the list, and disables all below it. So from there you simply make ONE function call in ALL cases, and pass it your current field, it'll then follow the rules.

What do you think? How do you manage ordered data entry and how you select appropriate fields?

I'll try implementing this and when I finish I will post here what my results were (pains/gains).

This is a rough idea, (not an actual implementation, but should be very close)

Using zip on the command line

I was trying to find zip on the command line, I don't know all the parameters that are available. However, a little guessing I added -r but anywho, this is the command.

zip -r filename.zip foldername

That's it.

Good luck