10 ways to mess it up at programming
I have recently gotten a web application from a nasty contractor who claimed to be a good expert in programming. Unfortunately, we believed him. Functional of the web application seemed to work okay at first glance. However, once the client started using application in the real conditions the things went bad. The contractor has gone after a payment, and I have gotten his errors to fix for a client.
I decided to document a few errors that I found along the way. These are errors that every good programmer should already know to avoid… but obviously some people need to be reminded about them.
10. Don’t store settings in a configuration file
When you are writing big application, information like the database connections and SMTP server will be used throughout the entire application. In order to protect your application from further support you need to redefine these settings every time you need them. So instead of putting those in the configuration file (Web.config or any other) you just scatter them all over the project. Whoever gets your application will thank you for walking round in thousands of lines of code just to change the name of SMTP server. What even better is when the next programmer finds the name of server only in 14 of the 15 places, and the last 15th place is somewhere deep in the application that makes it to work improperly. Sometimes it’s helpful to build the variables in inconsistently concatenated strings. Active partnering between the new developer and the disgruntled client will help strengthen their relationship. And if you don’t make this connection, who will?
9. Don’t store variables in any memory
One of the databases’ advantages is that they store information and allow you to access them whenever you need them. In order to make sure that your app is as terrible as possible you’ll want to access the database every time you need some information. The more often you need the information the bigger win you’ll have by making a new database connection to get that information. General user information fits better for this purpose. Don’t try to store the user’s information, such as “isAdmin” to a variable and using it throughout the current request. Just query the database each time you need to know anything about the user. After all, the client paid for that database, we should get as much out of it as possible!
8. Use covert plugins
If the client asks for a non-standard job, for example, to format tables in a way that is outside the abilities of your WYSIWYG editor. You should definitely find the unsupported closed source plugins in the Internet that will do the work for you. In order to write like this code yourself it could take an entire hour, you should spend at least 3 hours searching for and getting a plugin that does roughly but not exactly the same thing. In other words, this could be a good option to satisfy the client.
7. Don’t remove functionality
There are some moments in the course of the development of large applications, when the functionality that you were working on no longer required. In order to keep deadlocks and mazes for those who will continue to work on this application, do not remove this needless functionality. You could comment out random parts of it, or even hundreds of lines of it at a time, but don’t delete it. If you can make it to look needed without actually needing it, it will even keep the inheritor from deleting it. If your project uses source control and multiple server environments, make sure there is a different version for each server and source control. So nobody will know which one is in the production.
6. The hell with performance
Large applications are being used generally with large amounts of data. Sure, during your development process you create about 20 or more test records. I bet there’s no need to even worry about what happens when you have 25 records, or even 1,000! Obviously, if you split the data into pages - everything will work fine, and performance will always be different. So, if the application is compiled, feel free to give it to the customer!
5. Cram main logic/functionality in loops
As you already noticed in a clause 6 you work with large amounts of data. And inevitably often you need to run through the data in loops. So that your application has been really difficult to maintain, you must insert a main functional and/or logic inside the loops. For example, instead of having to query the database, throw all the data into memory and iterate over the array of data in the loop, you get all the data except for one field and go through them in the loop ... Then in the next loop, you have to get all data back from the database, but this time to include one additional field. This will ensure that your application will lie for five concurrent users (Re: # 6).
4. Document NOTHING
Everybody knows that the documentation is for morons. That means either you can read the code or you can’t read it, right? Definitely, the next programmer will be able to read the code. It is getting interesting when you don’t understand comments at all. There is a question: “Why does the documentation need at all?”
3. Use illogical variable names
If an application needs a lot of variables, you must select a movie or TV show that has enough characters, such as Lord of the Rings, Star Wars.You'll be using their names as variables. Maybe you can even make friends with the variables. Then you will not have to kill them! You can create variables chameleons, and then you can reset and assign them something new each time when you need a variable for the new functionality. They will grow and develop right in front of your eyes!
2. Catch all errors and do nothing with them
Nowadays, the majority of languages/platforms have built-in error handling mechanism. If the program crashes, it leaves enough details through the standard default error output. But you cannot leave it just like that! Start by wrapping every tiny piece of functionality in a try / catch phrase. And then inside ... catch insert a comment like "/ / Here is crap".
1. Duplicate functionality
If the client tells you that they need two pages: one for the administrator, where is a list of products with a delete button next to each product, and one for the average user, where is a list without a delete button, you definitely need to create two separate pages. Actually, if you can make a separate page for each user group, it would be even better. Create a separate page for each user is a 100% success. Concentrate and seriously consider the matter, since it is your last line of defense against the hordes of qualified professionals who will be trying to improve the well-designed Pandora's Box within your application.
This is not a complete list. I could name even more things that could make you suck. But I will leave 10 for now. Who wants to add a couple more things?
|Vote for this post
Bring it to the Main Page