What's your coding pace?
Posted on 12/6/06 by Felix Geisendörfer
Since a couple weeks I'm trying to pay a little closer attention to my coding habits to see if there still is some room for improvment (I'm sure there is). So one thing I noticed, was that I would always write 2 or 3 lines of code and then put in a debug() and directly check in the browser if it works. Sometimes I write more lines at once, but most of the time I work in very small steps. Now first I thought that it would certainly be faster to write whole blocks of code first, and then test them. But then I thought: "Faster? At what price?". Because if I would now start to quit my habit about short cycles, I might be done a little faster, but I would only have tested entire blocks of code, not most of the commands inside them one-by-one, which might leads to a decreased quality / stability of the source.
So I'm courious about what your programming habits are and what you think is a good style to adopt ; ).
You can skip to the end and add a comment.
[...] 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.
Thanks for those comments guys. Well, certainly makes me feel better about what I suspected to be a bad habit at first ; ). I mean coding big blocks can really fasten things up, but I often had them fail in other scenarios then the first one I used them in, because that was the only one I tested them for.
Any other ideas about programming techniques? Like auto-complete vs manually-typing arguments? Personally, I really enjoy Zend Studio's auto completion features as well as the function lookup when I Ctrl+Click on one. What IDE / features do you regulary use?
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!
About version control: Here is a policy that I adepted recently and that PhpNut_ is using as well. Instead of making the trunk your default working copy, create a development branch. So whenever you feel like you've written enough code to make a SVN snapshot of it, simply commit it to /branches/development instead of /trunk. So, whenever you feel like the code of your development branch reaches a stable status, simply switch your working copy to /trunk and merge the latest changes from the development branch into it (svn log is great to figure out when you did that the last time). Then commit the stable changes to the trunk. This way you always have a relatively stable trunk while enjoying the freedom of commiting little changesets to your dev branch whenever you feel like it ; ).
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
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.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
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.