Once an application has been wrapped up and delivered, is it over and forgotten about? Not usually. Once a package has been delivered, you can be sure that the client will more often than not, think of new features or changes. This isn’t a bad thing by any means, it happens very often in the software industry. This just means that as developers, we have to take care to create clean and maintainable code the first time around.
The first thing to keep in mind is comments. Your code shouldn’t need lengthy descriptions. If you have to write anything more than a simple one to three line summary of your function, chances are it is more complicated than necessary. Well written code can pretty much describe itself without too much thought. There are times when something has to be complicated, but generally those are exceptional cases. For the most part, there is no point in having a really smart and complicated way of doing something if it’s unreadable for anyone else on the team. The point here is to document your code and keep it simple.
Use meaningful names. This is really important for coming back to the code later on. If you have a variable called ‘x’ being used all over the place, well what does that even mean? If that variable was called ‘cmrName’ then it becomes pretty easy to see that you are dealing with the customer name variable. Also keep in mind to have good method, functions, and class names. For example, saveCustomerInfo is a much better name than processData. The first one says exactly what it does but what sort of data is processData actually processing? Meaningful name can save a lot of confusion later on.
On the point of variables, use them whenever it makes sense. Is a value being used multiple times across different methods or functions? It should probably be a variable at that point. Avoid hard coding frequently used values because if that value ever needs to change, instead of simply changing one variable value, you now have to search for everywhere that value is used.
Some other general guidelines are:
- Each of your classes should serve a single clearly defined purpose.
- Methods should generally be short. If they get too long and you have tabbed in too far, chances are you can pull something out into its own function.
- Your code should have one linear path for each action the user may take.
- Reduce coupling between classes as much as possible. If you have Class A and Class B and you replace B with Class C, there should be no changes needed or very minimal changes at the most. Classes should be as blind as possible to other classes.
So what does all of this actually accomplish? If you do have to come back later to make changes or additions, it will be quick and easy. All of these tips and practices will help make it so that making changes to your code doesn’t feel like untangling wires behind the entertainment unit. These are things I like to practice but I would love to hear any tips or feedback from anyone else. At Palm Beach Software, we are constantly looking for and applying ways to make everything as quick and seamless as possible for our clients.
