Wednesday, January 30, 2008

Coding Tolerance

Regarding Coding Standard, Instead of following something resembling Coding Standard I see what I have been doing lately is more of from the other way direction : Coding Tolerance. With standard, you define what you want and then define how things should be to meet those. With coding tolerance you start with let things be the way they are and then review what you can tolerate and do refinement when necessary.

Coding Tolerance can be looked as a bottom-up, pragmatic approach to making guidelines in coding. With it, you do not spend time in advance to try to cover all possible things that would mess things up. Instead you allow codes to contribute as long as you can still tolerate it based on your knowledge, experience, situation and condition you try to maintain steady progress.

Tolerating does not mean you start with zero rules. You define only small, substantial guideline at the beginning and refine from there case by case, item by item and refactor/streamline the rules when necessary. You don't judge the code from your coworker or from certain libraries by rigid syntaxtual standard, instead you try to understand why they got the way they are and whether you can still accept it considering your goal. There are many learning experience you'll get from it.

The insights we get from tolerating certain coding style is not just we can go relatively faster in short term (since we focus on getting things working), but it is beneficial for the future too. We could get insights on better way of doing things that we will not get if we just forcing insisting that our way is the right way.

So, the next time you try to define coding standard, try to define it from the perspective of what you can tolerate instead of the usual structure, style, syntax oriented rule. It might give you lighter, easier rule to comply that is still effective.

No comments: