3 ms·
You might be approaching PR comments differently than I've seen. When a comment is something to be addressed, it's either put into a new development task (i.e.
by christofosho 5mo ago
You might be approaching PR comments differently than I've seen. When a comment is something to be addressed, it's either put into a new development task (i.e. on something like Jira), or it is completed before the PR merges. I'm not sure that having comments in the code surfaces that information in a useful manner. The code is for the code, not for what the code could be. The comments on what it could be should be handled outside the code at a different abstraction layer.
- Aurornis 5mo agoAgreed. Putting comments in code is good for adding context around the code, but the actual action item needs to be tracked in the same place that all other action items and issues are tracked. An exception would be for information that doesn't yet qualify as an action item, but could become an action item if someone changes something in the code. Like if removing a conditional check would trigger the need for some other work or a refactor. Then it's good to put it close to the code so anyone touching that code will know they need to make the action items if they go down that route.
- waynesonfire 5mo ago> new development task (i.e. on something like Jira), or it is completed before the PR merges. You've never written an TODO comment? I find them useful.
- christofosho 5mo agoPerhaps in a small codebase without issue tracking this might be something leverage. It's just not reasonable with 100k+ lines of enterprise grade code.