One of the things I'm running into while working on DIC's Code Snippets is execution speed verses easy to use code.

For instance, when getting details on a snippet, it's easier to just return all the data on the snippet so it's there when I pass it to the template system. Also, it means the designer can come along and present the data however they need to. However, this doesn't lend to a "fast" application though since I'm moving around what can and is vast amounts of data that may not be used.

Another thing I've run into is calculating data on the fly. That is, calculating things like ratings instead of calculating and storing that data statically. I find in small settings this isn't a terribly big deal, however with the size of DIC and the Code Snippets, I've had to change how I do/did things.

So I pose this question, which do you prefer to use and why?

Ease of use first. I optimise my code on the fly as I'm coding, but I don't give it too much attention first. I need to get it working, before thinking about making it work more efficiently. I'm actually more worried the next programmer don't understand what I just wrote...

I found the optimisations I do make usually involve algorithmic or logic changes. The (increasingly better) hardware took care of the minor stuff I left out.

I try to use speed in code as opposed to readability because I don't normally have to go back in and add things. It's always been just me looking at the code. While I realize that's not the norm, I do go back and clean up the code and do commenting after the fact. Then the users can use the program, and don't notice a real difference when I make the changes to the versions.

What about if you are no longer the developer? If others need to read the code?

I try to approach it from both angles. Obviously, there are some common optimizations that can be taken into account pre-programming (especially if you follow proper development procedures and have a detailed design document), but others that will have to be implemented post programming once the performance has been measured. For those optimizations, I'll do those AFTER my code has been written in a readable state.

As for calculations, I try to leverage whatever can be done by the data source (a db usually) to try and end up with my calculations already done by the query. When that's not possible (and it has to be done in code), I try to shuffle massive calculations off to parallel processes.

My main focus is optimization, I use enough comments in my code to thoroughly understand what it's doing. We have a database with well over 10,000,000 records in it, and we applications being hit 50,000 - 100,000+ times a day (now multiply that by 8 web applications), and within the last year we've had over 120,000 new delegates added to the system so optimization is extremely important to my company.

Don't get me wrong, I don't write cryptic code, but with each line of code I write I have to ensure it's going to run as fast and efficiently as humanly possible. Like Amadeus, I do all my calculations on the database end whenever possible, otherwise Ill run complex calculations in their own thread so the application doesn't have to wait for that to complete before moving on. The trick with that is to ensure I dont need the results of the calculations before that process is complete, been there done that.

In the end, before releasing into production, I do my best to find a nice mix of both when possible, but for me optimization will always come first, I can always add more comments to make following it easier for the next developer.

This post has been edited by PsychoCoder: 30 Oct, 2007 - 09:30 AM

When I start coding something, I actually try to make it simple and easy to use as possible as I can.
Ok, I have to confess something, before I contribute for DIC site; I was too messy when writing codes.
I don't know why I have to comment the code, in my view that was a big wasting of time.
And I was writing lines which are very long and difficult to read.
But actually it works good.
And that was my bad, when other friends tried to read my code; they had to separate the lines from each other and wasting more time to understand it.
After I subscribed to DIC, I used to write more comments even if it's not necessary to me.

I always try to write the smallest script and free of logical errors as possible, but not if that will affect the efficient speed of progress.
To me, the simple of use came first.

"Optimizing Code Vs. Ease of Use." Without being too obnoxious about it, I'd have to say they're the same thing.

When writing code there's a lot of cut and paste and generally ugly stuff. Code that "finally works" is first draft, warts and all, not fit for others to see. However, that's when the real fun begins; refactoring.

Taking the unruly mess and grooming it. Making methods or functions where redundant code is found. Getting rid of things like "select *". Adding bind variables, defining constants. Removing old code that's no longer used and trimming functional code to make it leaner.

This process of refactoring inevitably leads to a kind of optimization and can often divulge potential bugs. The goal of the process is "ease of use" in the form of ease of maintenance. It creates code that ideally has one, and only one, place to go to fix a point of failure or make a global change.

I would definitely make the code make the code easy to use, while thinking about optimization. Like just try to make it so later on it is easier to optimize the program's code.

It certainly depends on what approach you have and your goal.

If you are working in a team:

1. Ease Of Use - So others are able to pickup from where you left, and make everyone's life easier.
2. Optimizing Code - As this can be achieved as a collaborative task and/or discussion.

If you are working by yourself:

1. Optimizing Code - Because you only have yourself to blame if it's slow.
2. Ease of Use - Because if it's closed source only you have to understand it.

This post has been edited by RodgerB: 2 Nov, 2007 - 06:20 PM