|
|
|
|
|
|
by iimblack
746 days ago
|
|
|
IME hard disagree. Projects with any longevity and/or turnover will have code that doesn’t seem to make sense but was put there for a reason. Commit messages are key to giving the context because even though there might be descriptions people will put the relevant slack messages and jira tickets in the pr or commit. At this point I almost weekly have to review the full context on a pr to make sure my fix won’t break some historical use case that isn’t immediately obvious. |
|
|
I'd argue tests are much better to guard against accidentally breaking contracts, since they can tell you when that happens, and even why it's important that it doesn't. If that doesn't work, code comments are also good, since they are immediately attached to the relevant code, even if it's refactored and moved elsewhere. "// this looks wrong but " is pretty common in my code.
Warnings in commit messages may be irrelevant, and the deprecation notice may not appear in the same "git annotate".
Especially for projects with any sort of longevity, the commit log is an awfully large haystack to keep such important needles in.