Die, spaghetti-code, die.

3610270537

I never really got what spaghetti code was until today. That might sound dumb, but it’s a term that is quite widely-used in different contexts so it can be an odd one.

Today, I have been working with code that is devoid of any design, regard for future developers or useful documentation. Like so much PHP, the end result works, so it’s great. Except it’s not.

Imagine each line above is a function or method call, which has its own integral part to play in the execution of a web page (in this case). The entry and exit points are single entities, but what goes on in between is nothing short of scary!

3610270663

Ideally, I like to see code the main vein of which is there at the start and the end of the app’s execution. Logic can branch from this as far as it wants to get what it needs, but it’s ultimately serving a purpose for the main line. The more I delve into OOP in many languages, the more I realise that procedural code is quite liable to spaghetti, whereas OO is not. That’s not to say it’s impossible, but it’s easier to have one method that sets everything in motion, configures your program and then receives and redirects input in OO than it is procedurally.

Since I started properly getting into OO, I started to liken the execution cycle of a procedural program to a glass of water falling. Everything starts from the same point, but over time everything splays out and does its own thing. Debugging procedural code, therefore, is analogous to blindly cleaning the aforementioned spillage – there is a good chance that the part of the spillage you’re working on has nothing to do with what you’re actually trying to achieve – no matter how relevant it looks!

Unfortunately, I blame PHP for the natural progression of spaghetti code from procedural to half-assed-OO. It’s so easy to get things done without really knowing what you’re doing that it’s actually borderline dangerous. A mishmash of procedural and OO is the absolute worst thing to debug, as it normally combines the horrible execution cycle of procedural apps with the potentially confusing trail of inheritance. Let me tell those who don’t know – it is VERY obvious when you’re working with code written by someone who does not understand inheritance (and I don’t mean what it is, I mean *why* it is) and it almost always makes their half-baked bastardisation of OO impossible to work with.

Have I had a difficult day? You could say that.

Utter failure

Today reminded me of when I first started writing web applications. When I first started glancing through PHP, and I didn’t have a clue what was going wrong, why things weren’t working, or how I was going to fix it. Until, right at the last minute, I took a step back and actually read the thing I thought was right, only to discover that it was totally wrong. I then wander to the lounge, dejected and beaten and look at my family, asleep and waiting for me.

Sometimes I wish I didn’t have this obsessive need to solve everything right now. I keep missing out on the important things in my life because I’m so paranoid that a fresh pair of eyes won’t fix the problem I’m having. Tonight, I was so frustrated that I actually cried and shouted and drank and wished for cigarettes. I’m so pathetic. I worked through deliveries of photos of my babies being cute, and my wife being sleepy and adorable, just to reach the realisation that I need to really look at a problem and stop wasting my time thinking that working harder, or swearing more will solve my problem. Stupid, stupid, stupid.

I need to sleep more, not just go to bed and stare at the ceiling.

260: Documentation

3285282297

You try being creative when you’ve spent all day describing parameter data types.

Working days

I’m all for reusable code. Whenever I’m coding, I’m constantly wondering if there’s a way that I can further abstract what I’ve done so I can use it somewhere else. Because of this, I came across a problem yesterday that got the better of me a little.

I’m working on a project at the moment that requires me to have an awareness of “working” days. Specifically, when a product is sold, the customer has three working days to cancel their order. This would be all well and good if there was 365 working days in the year, and all companies were the same. I started out with this assumption, but was quickly confounded.

Before I explain how I solved (well, only partially – it would require a calendar app to fully solve it to my satisfaction!) it, I’ll explain a little about how some classes come to be in my workflow.

Twitterminal – A Terminal-based Twitter client in Python

So, I’ve just started looking at Python, and I love it. Last night I was playing around with django, which is ridiculously cool, and tonight I started a Terminal twitter client – I’m dubbing it Twitterminal. Imaginitive, eh?

It’s crazy-simple, and I’m not bothered about people using it or ripping it off so go for your life! The Twitter class, twit.py: