Eric Biven's Blog

When I began coding I knew that my application had to fit in 16K of RAM. That’s all my Timex Sinclair had, including the RAM expansion pack. It also didn’t help matters that the keyboard was covered in a sheet of plastic, but we won’t get into that. The point is that my code had to be lean and mean if I wanted to be able to get it on the machine at all. As I’ve become more sophisticated I’ve added bulk to my applications in areas such as error handling and user interface functionality. My applications (and in turn my customers) benefit from the additional functionality provided by that extra code. As the years go by I also add more comments than I used to. I’m finding with experience that any maintenance programmers will need the hints, even if that maintenance programmer is me. I’m going to go off on a quick tangent about code comments here, so bear with me. If you just can’t stand it skip to the next page. Ok, code comments are wonderful and necessary but they are incorrectly used all to often. For people new to coding, follow this simple rule: “Comment about why you did it, not what you did.” Seems obvious enough, right? If I had a nickel for every time I’ve seen this in someone’s code I wouldn’t need to by typing these articles: // This is a loop while (somevar == “value”) {… No kidding huh? That’s a loop? I couldn’t tell by the “while” declaration. Now, can you please tell me WHY you’re looping through 3,000 records in a database? Was there a reason you brought back records you won’t be using? Inquiring minds want to know. Anyway, back to the main attraction. So this brings me to the disturbing trend. As I’ve seen storage, CPU speeds, and memory increase so has the absolute slovenliness of the code I’ve worked with. It’s beginning to get almost comical in some instances. People are beginning to lose the fine art of writing efficient code. This isn’t to say that you should make your application’s features Spartan, however I am saying to cut out things that don’t add to the application’s reliability or functionality. You would be amazed with some of the things I’ve seen written into apps. People using enormous and buggy message queuing frameworks to marshal simple requests between processes on the same computer, for example. Now, some applications deserve to be huge, some need to be huge. However, if your application is over 100MB compiled and all it does it track time against projects you might want to look around for some fluff. Of course it doesn’t stop with the code itself. It also seems that minimizing the transfer of data has become irrelevant. The dawn of high speed Internet access has allowed people to send a richer experience to their users. This has given birth to two and three MB websites. What is it that makes up most of that size? Intro movies, background sounds, and spinning, jumping, flashing things. It seems we didn’t all get the hint when IBM ran their “spinning, flaming logo” commercial several years ago. Then there are the new .NET based web applications. While the .NET framework is wonderful in the hands of a skilled developer it’s simply dangerous in the hands of amateurs. Take view state, for instance. It sounds great that you can pass things back and forth from the browser to the server without any effort, right? What some coders don’t realize is that for every control with view state they are transferring a significant amount of data in the background. I’ve heard tales of pages with 30MB of view state data alone. Tell me that isn’t an issue. So what is causing this? I can’t tell you that it is being caused by the increase in computer capacities, only that they seem to be happening simultaneously. It could be that more speed is allowing us to get away with being the lazy coders we always were. It could be that the advent of all the frameworks and forth generation languages are allowing less talented people into the industry. For all I know it could be a conspiracy of purple monkeys running the whole thing from Argentina. I’m not betting on that last one, however. It’s probably a safe bet that it’s a combination of reasons. We each need to look at our own efforts and say to ourself “do I really need that or can I refactor that and come away with something more efficient?” We also need to be sure that we understand our tools and the ramifications of using different syntax. For example, if you’re declaring a string in php and it won’t need expansion use single quotes to declare it. There’s no point in having the server sift through your string looking for variables and escape sequences when you know there won’t be any there. I frequently hear “but the load is negligible at best” when I point things like this out. My response is that while that may be correct, there is extra load and the difference in time to code it is non-existent. Another lost art is the optimized database query. I occasionally run into a piece of software that will have entire tables returned, only to have a loop that processes out 80% of those rows. Now, if you only needed 20% of the rows from that table why did you make the database read them all, then send them all to you? Also, the database server is tuned to sort out that data. That’s one of it’s primary jobs as a matter of fact. SQL is a wonderful data manipulation language and is relatively simple to become “good” at. I spoke not that long ago to a group that had an application written for them that crashed when they went from the lab to production. The reason? The developer had each

Read More…