An entity without standards is chaotic. I’ve seen, experienced and even generated my own projects that had no standards (back in the day). From all these, I’ve seen some common traits:
1) If the coding takes long, like more than 16 hours, it starts to get complicated to work through and keep things in the bit of architecture you originally intended.
2) You find that as you move along, you need/want to rebuild parts of it to simplify them or just because that part doesn’t make sense to you anymore.
3) After leaving the project and coming back, or entering a new project from someone else built the same way, you tend to think it would be easier to rebuild the whole thing, than work with the existing code.
4) You lose track of the meaning behind certain methods, classes, variables and processes, and when you look at it, you don’t understand how it seemed so clear at the time.
5) Bugs start showing up all over the place.
5) Bugs start showing up all over the place.
6) You start applying little hacks here and there that keeps things working in very specific conditions.
7) Fixing a bug usually produces two more, 1 you get to see right away, and hides out for a little while.
8) If any timeline was generated, it has been exceeded.
9) If the project isn’t very important, the developer will drop it.
10) Developers get sick more often due to stress.
11) It is fun to start, but after a short time, the fun is gone.
The list goes on…
If you find your code, team or other’s suffering from the symptoms, it’s a pretty good sign there is a lack of a standard (at least a good one). I’d also like to point out that a programmer without standards does not make them a bad programmer, but it does make their code more susceptible to the symptoms above. Just like OOP is a step over the basics, having solid standards is a step above that.
So I’ve listed some of the bad things that happen. Now on to the solution.
When it comes to standards, I’ve got a saying. There are many right ways, and many wrong ways, but only one right way. :D (it makes sense in a moment) The point is that while there are many good standards to follow, you have to choose one and stick to it. Standards are no good if they are not standard. 2 weeks ago, I posted a way to document standard processes. (here) Now I’m going to give you some ways to find and keep your standards in specific.
The first thing is to know why you follow something. There are many outdated standards, which are outdated for good reason. The second is to be open that your own style might not be the best. (This is something I consider all the time.) Hungarian Notation was pretty big for a while, until they realized (not everyone knows this) that by following Hungarian Notation, you are actually reducing the implications that should be used through vocabulary. Lets take a look at 2 variables “_adAmount” and “prices”. Looking at the Hungarian Notation on the right, which is using an “_” to show it is a private variable, “a” to indicate it is an array, “d” to indicate it is of doubles, and “Amount” to give it a name. Now, following some more modern standards, we see “prices” which is lacking all the symbols and details of “_adAmount”. It is lowercase, indicating it is private. Price indicates a decimal is needed and also implies the accuracy needed of a double. The fact that it is plural implies an array of some sort. Both of these followed a standard. Hungarian got away with “Amount” though. Amount is questionable, amount of what? Amount of time since the last loop? Amount of apples? There is nothing in Hungarian Notation standards that sets up the implications of its meaning.
Sure, you could have chosen “_adPrices” as your variable name, but what standard are you pushing that requires that? Another developer may have entered this and just used “I” or “x”. The point is that the word is often chosen because the developer needs a “notch” to refer to for a variable. If it’s only for a single method, they often use smaller less obvious terms. While these work great for the quick entering of data, in order to figure out what it is, you have to take a look through the code to see how it is used. I recommend keeping a standard where things make more sense, and are easier to read with native English.
Now to the key point, 1 true standard. The point is for you to write down your standards that you will follow. But, you also need to record the defenses with it. (Why this is best) And finally keep it open for critics. Anyone who works with you, should also follow this standard, or successfully argue why to use something different. You are not allowed to use a “because I said so” or “because I’m above you”. The whole point of this is to make better code, not stick to some obscure ideology you grew up with, because you aren’t open to change. Be practical. When you write down defense, also include challenges to it, even if you keep that one. Later on if you find a better way that solves more, then upgrade and keep it. Don’t hold to practices that are not defendable. You’ll find yourself hurting in the long run, and may not even realize it.
One Standard: All standards are defendable, or they are not standards.
One Standard: All standards are open to change from anyone who has to use them.
One Standard: Have a standard.
One Standard: Keep it practical.
One Standard: Keep it Easy to find, Easy to read and Easy to use.
One Standard: KISS: Keep It Simple Stupid.
One Standard: Keep it flexible.
One Standard: Keep it living.
No comments:
Post a Comment