debuggable

I do the same thing. I'll build out the skeleton and then as I start to add the meat I'll check my work fairly often. I think it has something to do with feeling some satisfaction in my work. It seems to keep me motivated.

[...] I stumbed through this article today. It talks about the author himself’s coding pace. I’m somewhat similar to the author. I write about 3 to 5 lines and then I run a check to make sure everything it good. I sometimes really think this is slow. I’ve attempted to code a whole page without checking. It goes much faster, but I don’t think the time going back to debug and fix things is worth it. Just my view. [...]

I do that a lot. And it's not just programming: I do it when web designing too, even though I know how it will output. I guess it's not just you.

I think I do it for two reasons: Incase I made a mistake, or, just to see how my progress is doing with the script.

I'm glad I'm not the only one! ;)

I've always thought my pace was pretty slow and that I was the only one spending more time refreshing & debugging the page/application then actually writing the code, but I guess not.

The big advantage for me is that when something breaks, I know what caused the problem. Coding huge chunks at once would leave me wondering what exactly triggered it, and the debugging ended up more extensive with lots of "break points" & debug()'s after each function call/statement.

I have a tendency to do the same as you but maybe in larger chunks. I now write functions or methods before I begin testing. That is, unless I'm doing something I don't really understand (50% of the time?) :) In those cases I will throw in var_dump() until I know what's going on and then finish up.

You bring up a good point though. I know developers who will write all their code and THEN debug. I find I can't do this because by the time I get finished and start debugging, I'm out of 'the zone' for the code I'm now debugging. If debug immediately after I write the code I find myself asking a lot less "Why did I write that?' :) Could be that I'm just getting old.

=C=

I use PHPEclipse for most of my project work, and PSPad for my quick single file editing needs.

On thing I really like about PHPEclipse is it's on-the-fly syntax checking. As soon as I save the file it highlights any syntax errors in the code itself.

Which saves me having to go back to my browser and wait for it to re-run the page and spit the syntax error out, and then having to go back and find the line of code.

That adds up to be a lot of time correcting measly syntax errors!

PHPEclipse also works really well with Subversion or CVS to make committing my work very easy.

The only downfall is that it is not very easy to simply edit a file via FTP - that's where I use PSPad.

Very interesting point!
My coding style is quite similar to you.

If I try to write a large chunk of code at once, it requires me far more time to debug it later on.

But I wonder how I can improve my performance in terms of not only speed but also progress.
I've experienced losing concentration several times when I did seemingly large chunks of codes in relatively short time then, wasted much time on playing around.

In other words, for me, short-term coding speed does not equate to the actual progress on the project since I often lost the track on my code time to time.
Is there any technique to keep your concentraion on the codes more effectively?

Share your wisdom, please.

I too do the same and thought it was bad practice. I was wondering how others coded and debugged and from the comments in this post it seems we are all similar.

There is one thing I do that I still think is bad and that's leaving the debug statements in the code (just commenting them out in case I need them later). Sometimes I don't even comment them out. I just leave them there so I can see the changes to application data at the different stages. This is bad because my redirects don't work due to the text being output before the headers.

One thing I've started doing is 'Test Driven Development' (for models at least). This allows me to feel more comfortable about taking out my debug statements and trust the test passing code. I've been trying to restrict my debug statements to the tests themselves so that the actual application is without them but there is only so much you can check in the tests only.

One more practice I've been wondering about is version control practices. I never feel right about checking in half written functions or code segments and so I try to wait till a function is finished before committing the changes. I'd be interested to know what others are doing.

BTW Felix: I could read your blog all day!! Great stuff!

Sonic

Mhh even when I hate the BDUF(1) design pattern I find that some times I just *know* what to do. I let myself go, banging out code until the page is pretty much complete. It works as it is 50% of the time and that is very satisficing.

When there are bugs i find i can go back at them very quickly and many of them can be corrected at once so its really faster.

But it depends on my mood a lot, really...

1.- BDUF: BIg Design Up Front

Felix,

It's been almost two years since your last comment on this, and I'm curious whether you find yourself coding a little more and testing just a little less. I haven't coded PHP, ASP or anything inline with HTML for years, but I still do test like this. Not as much as I did two years ago though, and looking forward, I think the greater my mastery of a given language, the less I'll test like this in it.

Thoughts anyone?

dblanchard