Recently I heard aboutBoy Scout Rulethrough one of the presentations by Robert C. Martin. I must say on a high level one may say that this is more of a common sense to follow this rule. And probably there would be people who are already following this rule in the name of common sense and may not know that this common sense is actually termed as Boy Scout Rule. But I admit I could not apply this common sense prior to hearing about this rule...
This post is for those who do not know or hear about Boy Scout Rule already. The basis essence of Boy Scout Rule is to make the code cleaner every time you work on it. Wonder how...? Keep reading...
How often it happens that we may work on a piece of code/ module which you think needs some (if not more) rework. Rework in terms of following code conventions, removing duplicate code, to remodel it to make in more OOAD oriented design, to add comments for a complex piece of funtionality or even remove comments if they do not help much.
But the question is how often do we go ahead and make those changes. Some may say always, some may say sometimes and some may say never - fearing that
1. It may have some adverse affect on rest of the functionality or system all together.
2. Project is on tight timelines and there isn't any time to fix the code which somebody else has written.
3. Or we just do not want to take the pain to fix it (if this is the case then no rule can help it ;-))
I agree with these points and I think this is where Boy Scout Rule can help. The rule simply states that whenever you work on a code file try to make small change in it to make it better before you check it back in. The change could be as small as adding some comments for an uncommented function, variable or renaming a variable to make it more meaningful. So that the next time when a programmer works on that code s/he would get a little bit cleaner code than before. Keep following this practice untill all your code bases becomes cleaner.
Imagine if entire team starts to follow this rule, how quickly your code will start to improve by making small small changes at a time.
If you follow Test Driven Approach (TDD) then this rule can do wonders for you. Because with each code enhancement that you would make, you can simply run your unit tests to see does it break any tests or not.
I have now started following this rule and can easily see the advantages of it.
The other, side advantage of this Rule is: You can break the ice by starting to talk about this rule with-in your project team to impress them with your thoughts :-). However do not forget to give credit to Robert Martin
This post is for those who do not know or hear about Boy Scout Rule already. The basis essence of Boy Scout Rule is to make the code cleaner every time you work on it. Wonder how...? Keep reading...
How often it happens that we may work on a piece of code/ module which you think needs some (if not more) rework. Rework in terms of following code conventions, removing duplicate code, to remodel it to make in more OOAD oriented design, to add comments for a complex piece of funtionality or even remove comments if they do not help much.
But the question is how often do we go ahead and make those changes. Some may say always, some may say sometimes and some may say never - fearing that
1. It may have some adverse affect on rest of the functionality or system all together.
2. Project is on tight timelines and there isn't any time to fix the code which somebody else has written.
3. Or we just do not want to take the pain to fix it (if this is the case then no rule can help it ;-))
I agree with these points and I think this is where Boy Scout Rule can help. The rule simply states that whenever you work on a code file try to make small change in it to make it better before you check it back in. The change could be as small as adding some comments for an uncommented function, variable or renaming a variable to make it more meaningful. So that the next time when a programmer works on that code s/he would get a little bit cleaner code than before. Keep following this practice untill all your code bases becomes cleaner.
Imagine if entire team starts to follow this rule, how quickly your code will start to improve by making small small changes at a time.
If you follow Test Driven Approach (TDD) then this rule can do wonders for you. Because with each code enhancement that you would make, you can simply run your unit tests to see does it break any tests or not.
I have now started following this rule and can easily see the advantages of it.
The other, side advantage of this Rule is: You can break the ice by starting to talk about this rule with-in your project team to impress them with your thoughts :-). However do not forget to give credit to Robert Martin
No comments:
Post a Comment