But what should you do when one of guidelines are not part of your ‘believes’? For example adding a comment to each public class/interface or method.
There are developers that will NOT respect the guideline, will fight for it until the end of the world and will say NO – ‘I will never respect this guideline because is bullshit’.
This is an extremist approach and I think that this approach is not better than the one when you accept everything. In this cases the most important thing is communication. You need to understand why that guideline exist (it came from the team, architect, PM, company or client).
You should explain why the guideline is not good, but be aware, one time is not enough, because you may have people that use that guideline for 10-15 years and for them is a religion. Small steps are the best option in this cases.
But if none of the solutions works and all the team say that the guideline is good then you have two options:
Respect their decision, write code using their guideline (you didn’t lost the fight, but you need more mitigation – time is your best friend)
Leave the team and the project (the extremist developer : - ) )
The worst thing that you can do is to write code using your own guidelines. Even if you don’t like the guidelines, you should not ignore their guidelines. If you have 1 million lines of code written using a specific guideline, starting to write a part of the code with your own guidelines is a big mistake.
It is okay to write a small PoC where you can show them why that guideline is wrong, without making a push to the main repository.
In conclusion we could say that being a new member in a team can be hard, but you need to be a team player and accept other believes also.
From my point of view, sometimes three lines of comment are not enough, but sometimes one line of comment is too much. There is no sense to set up a policy that requires comment for every public methods, because many methods can be trivial and described correctly by their name. On the other hand, if the method does something extraordinary, than more comments are required. If we set up a policy that every public method should be commented including the trivial ones, programmers will hate commenting, but the quality of the comments will be strange. I think, there is no sense to add a comment "Gets the users" to the method GetUsers, not to mention the trivial public properties. What is the intention of adding comment? Increasing the size of the code or adding extra data which can't be read out of the code?
ReplyDeleteThe comments rule was only an example for coding guideline.
Delete