How many of you go back and tidy up your code?

[andymc]

I spent an hour this morning on my commute tidying up my games code, I've managed to reduce it from around 1150 rows to 1040 rows of code. I've also improved the comments so I will remember what everything does in future and other people can read it easier.

I'll admit it was boring, and every time I moved a block of code, or wrote a new sub to replace multiple blocks of code I was worried it would break everything.

But it feels good now I've done it, and it's now easier for me to take blocks of it to use in other games!!!

 

[sorex]

I never comment my code unless it is a routine that I write to help someone out and they need it to understand what I did.

 

[sorex]

by the way that would be a nice idea for another compo, code a game within 256 lines or something

 

[Troberg]

I often go back and refactor code. If I find that code becomes too convoluted or messy, I refactor. It's so much worth it in the long run.

I like the term "technical debt" to describe the effects of bad code. If that debt is not repaid (by fixing the code), it will keep on accumulating interest by adding cost and further debt every time you add things to the code.

A related issue is "Fix existing bugs before adding new features".

https://en.wikipedia.org/wiki/Technical_debt

 

[RandomCoder]

I continually tidy and comment my code but that's because in my day job there are other engineers and tradesmen that have a difficult enough job without me adding to it. I like to think that when they come across sections of code that I have modified they feel happier knowing that it was done by me. But with Android programming it is just a hobby and so I only have myself that normally needs to undarstand the code, having it well documented helps me to follow my own train of thought when sometimes long periods can pass between coding sessions. It's also useful because I can often just copy and paste functions to the forum with litlle or no modification.

 

[JordiCP]

Sometimes I comment more than I code, just as a message (telling why the hell did I code it that way) for the future-me (I have a terrible memory), who will read it later.

by the way that would be a nice idea for another compo, code a game within 256 lines or something

This reminds me of the old 4Kbytes contests. Searching in the internet I have found THIS . Amazing!

 

[Troberg]

I usually start by writing the comments, then fill in the code. That way, I can focus on the "what to do" rather than the specific details of the implementation.

 

[RandomCoder]

I usually start by writing the comments, then fill in the code. That way, I can focus on the "what to do" rather than the specific details of the implementation.

I've never thought of doing that but kind of like the idea. Maybe I'll give it a go in my next project.

 

[sorex]

This reminds me of the old 4Kbytes contests. Searching in the internet I have found THIS . Amazing!

yeah, I was at that party when it was released. The year before there was something simular but rendered to a movie.
I remember it mentioned that it took 2 months of calculations

 

[MikeH]

I`d love to have a demoscene like there was for Amiga. In fact, when I get time (haha) I might make one just for the hell of it

 

[AHilton]

Rarely, do I refactor code. Unless it's a matter of adding features and needing some routine pulled from base code into a reusable class or function, (coding) life is too short to refactor. As far as commenting code. I heavily comment. As I tell any new programmers, you comment not to explain WHAT you're doing but WHY you're doing it. The WHAT is explained perfectly well (or should be) by the code itself. I work on so many different projects, languages and platforms that if I didn't comment, I'd spend most of my time jacking with past code just figuring out why things do what they do. ha!

 

[andymc]

The demoscene never died!

 

[Troberg]

The demoscene never died!

Perhaps it's not dead, but it's certainly not in it's prime...

 

[KMatle]

When I take a look to the last apps I've made, my coding is getting better. At least I don't come to that point when I get angry about the sh*** I've coded.

Best example: On my first bigger app I had a lot of edittext's and FOR EACH I had a sub with XXX_TextChanged. It took me some time that there could be a better way...

 

[HotShoe]

I write comments when I'm tired or under the influence of some outside force so I know what I was trying to do. That way I can come back the next day, delete those routines, and start again.

--- Jem

 

[JakeBullet70]

I comment depending on the speed of my brain. (Good variable names do help) I do though refactor some times if the project is LARGE to make it more maintainability and to help the programmer coming after me.

 

[WAZUMBi]

The problem with 'going back' and attempting to tidy up code is that often times, in larger more complex programs, changing one seemingly simple line of code in an attempt to make it more logical or tidy destroys the entire program.

Sometimes you forget why you did the strange things you did. I've done this more times then I can count.

I go back and review my code and attempt to fix things. Oops!
It then take me hours to figure out again why my otherwise 'bug free' and working program suddenly is broken. I then have to back and put it back the way it was.

In my experience while developing a program often times the more logical approach is not the best approach to a solution. Of course I don't have worry about a future programmer coming after me. It's just little ol' me.

Even now, with commenting, when I go back and update a program I rarely alter the original code unless it is critical to the update and added features.

No matter how ridiculous it looks, I trust myself to know there must have been a reason why I did the weird things I did...

 

[Troberg]

No matter how ridiculous it looks, I trust myself to know there must have been a reason why I did the weird things I did...

Oh, there's always a reason that I did strange code. It's just almost never a good reason...

Usually, bad code is a result of not knowing how to solve a problem before implementing a solution, adding features not really fitting into the code or simply growing too large.

One often overestimates the cost of a refactoring, and underestimate the cost of not doing it. Even more so if refactoring is an ongoing process, which is done before things get really bad.

I like to treat my code according to the Scout rule: "Leave the campsite a bit tidier than when you arrived". Leave the code a bit neater than when you opened it.

 

[RandomCoder]

@Troberg dib dib dib, dob dob dob

 

[Troberg]

@Troberg dib dib dib, dob dob dob

I think that reference went over my head, I have no idea what you are talking about.