Simplicity
Years ago when I was a student, I remember how we thought a complex code was done by someone who knew a lot and a way of showing yourself was to write pretty complex code lines no one even you weeks later could understand.
Simplicity means even an external programmer to the project should be able to understand what it does in a quick sight, if that happens, you will also be able to do that and that will help you with maintenance.
Should I care about external programmers?
There is a saying in Programming World that, if you became indispensable in your company, maybe because your codes are impossible to handle, you will never be fired. First of all, you will never be indispensable, it may cost more to them, but you cannot fully obfuscate a code and even if you can, codes can be redone. So, don’t waste your time making yours and others life more difficult.
Also, you will notice that, after a while, maybe some months maybe a year, you’ll forget about your own codes, not remembering why you did this or that. So the best way of helping your future self is to write simple codes that even your future self drunk could understand.
Let’s see an example
This:
function hahahah(e) { var thirteen; if (window.event) thirteen = window.event.keyCode; else thirteen = e.which; return (thirteen != 13); }
Should be this:
function disableEnterKey(e) {
var key;
if (window.event)
key = window.event.keyCode; //IE
else
key = e.which; //firefox
return (key != 13);
}
I know, it’s not a good example, but I don’t have anything in hand atm. I will update it when I think of something better.
Use some comments
Despite we try to make codes simple we’ll find that sometimes that’s just not possible. When that happens, a few comments to explain what it does will help. Also, if the code has a tricky issue, a warning comment will be pretty useful (remember most probably you will be the one who, in 7 months, will have to maintain that code, and you don’t want to provoke a bug).
/* WARNING: Some styles of this object are set dynamically at its back code*/
.CustomGraph{width:290px;border:1px #eee solid;float:left;margin:0;padding:10px;}
.CustomGraph h4{margin:0;}
.CustomGraph .data{height:250px;background-color:#fff;overflow:auto;}
.CustomGraph .data table{margin:15px auto 0;}
.CustomGraph .data img{margin:0 auto;display:block;}
.CustomGraph .data img.expandable{cursor:pointer;}
Don’t Repeat Yourself (DRY)
When writing codes it may happen to you that you make a function for one place in your project and then you need to do the same thing in another place (like a validation when adding a user later on you realize you need for updating the user too). When this happens, the temptation to just copy paste the code is big, but doing so, your code will tend to bugs and problems.
If you need to change that user control in the future you may forget there are two places where you have to do the changes, or even when you don’t forget, if you are touching that code, between modifications the two (or three, or four, …) copies may end being different in one of the changes. The best way to avoid this is avoiding repeated functions in the code.
You aren’t gonna need it (YAGNI)
YAGNI (You aren’t gonna need it) is an XP principle that prevents you from writing those things you think you are going to need later but that lots of times you don’t need in the end.
When we start designing we open our mind thinking of all the possible actions a user could want to do or the project could need to do. As a result, we tend to build incredibly big structures for something much more simple, increasing the project complexity and giving us more work. The YAGNI principle prevents you from this making you build just the things you really need and not the ones you think you could need, increasing the development speed and the project flexibility (less structure, more flexible). That’s why this is called Agile 😉
Last Responsible Moment
Continuing with YAGNI we have the Last Responsible Moment principle, which consists on waiting until the very last moment before doing something, this way you give more time for design or behavior decisions to be taken and help yourself not having to rewrite it. If you have worked as a freelancer like me, you should be used to your clients changing their mind 15 times about were the logotype is going to be placed or if they will add the “Share in FB” button or not.
Not only that, in terms of Back End, you may know you will need some class, but instead of making it from the beggining is better to wait until you really need to use that class to write it. Not only because domainers may change their mind, but because your design may be redesigned by yourself as you keep going on the project and realize you need this or don’t need that.
So, don’t build all the classes “structure” at the beggining, instead, start building a class and the ones you need as soon as you need them, this way you will design them knowing the project and its needs better and adjusting them to the project instead than having to adjust the project to fit something you designed at the start, when you didn’t know that much about the project.
