Showing posts with label coding. Show all posts
Showing posts with label coding. Show all posts

Thursday, May 14, 2009

Slow news day?

So Jeff at Coding Horror decides to post something pointless. Well, perhaps not because it somehow manages to become topical because of today's successful Ariane launch and the clarification of the Ariane failure in 1996 (read the comments for that.)

All programmers know the term GIGO. If they don't, then perhaps an alternative career should be considered. Accurate number storage has always been an issue, so I would expect that any post about it in the 21st century should be putting forward a practical solution, not leaving it as an exercise for commentators.

Monday, May 11, 2009

Code vs Pseudocode

I just read this post over at Coding Horror and find myself agreeing with much of it. I always found that writing pseudo code was more of a hindrance to writing proper code in the first place.

It probably makes sense to write pseudo code if you're not going to be doing the actual code yourself. Otherwise, there are a few traps you can fall into - You can get bogged down in putting more detail than necessary in the pseudo code because you're thinking of the actual code that's going to be written and you can also lock yourself into a particular way of thinking that blocks the process of writing the code, because the pseudo code described the functions in such a way that the language being used to write the code doesn't translate well.

I would say writing pseudo code is a particular skill, best left to those who are good at it - They may or may not be coders, or good coders at that. I've found that when writing code, I tended to go straight from the big picture into code, and trying to think about how to get there ended up muddying the waters.

My guess is that for a large project which is going to need long-term maintenance, it makes sense to have someone look at the overview and break it down into pseudo code before any coding is done, otherwise it's probably better to have the coders build up the higher-level documentation as the code is written.

Perhaps the way of thinking that makes most sense to me is that as a writer, you wouldn't write your table of contents first and then the book unless you have a very firm idea of what's going to be in the book. I'm sure most authors would block out their ideas, come up with their characters and motivations, and main plot event and let the story grow from there. A lot of people don't realise the creative input that's needed to write code - It's a bit more than just putting blocks together, no matter how many design patterns have been learned off by heart.