I think you’ve hit the nail on the head. I worked on a team that disliked docblock comments (and would fail my code reviews if I included them). Their rationale was that any amount of commenting would allow a developer to become lazy when naming methods and variables, or wouldn’t extract functionality out. While I agreed on some level, the wholesale refusal to merge code that contained any comments at all seemed overkill. All too often I stumble across code that appears to be doing something odd, or a “better” solution is very obvious to me in that moment. In the rare cases that I’m able to discuss those past choices with the original developer, the reasons why are usually illluminating. Being able to communicate why something needs to be done seems like the best middle ground available, and is something that I try to be mindful of when I’m authoring or refactoring code. Good article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you’ve hit the nail on the head. I worked on a team that disliked docblock comments (and would fail my code reviews if I included them). Their rationale was that any amount of commenting would allow a developer to become lazy when naming methods and variables, or wouldn’t extract functionality out. While I agreed on some level, the wholesale refusal to merge code that contained any comments at all seemed overkill. All too often I stumble across code that appears to be doing something odd, or a “better” solution is very obvious to me in that moment. In the rare cases that I’m able to discuss those past choices with the original developer, the reasons why are usually illluminating. Being able to communicate why something needs to be done seems like the best middle ground available, and is something that I try to be mindful of when I’m authoring or refactoring code. Good article.