this post was submitted on 10 Oct 2024
1 points (53.8% liked)
JetBrains
169 readers
3 users here now
A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/
Related Communities
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Copyright ยฉ 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.
founded 9 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@BatmanAoD And every developer should take the time to create a meaningful commit-message for the work they did. After all they invested a good amount of time into the code change, so why not proudly explain why they did it, what the challenges where and why they did it
*that* way?
But on the other hand: It's documentation, so just drop it ๐
Also: Code-comments are fine but tend to rot during code changes. The commit message is always tied to the commit.
It's not documentation, though. That's my point. It's a byproduct of the development cycle, not a place to store important information.
Commit messages are tied to a commit, sure, but why do you expect developers to have better discipline in writing commit messages than they have in updating code comments?
@BatmanAoD Because the commit message is a requirement when committing code. The code comment is sitting there and no one cares whether it'S updated.
And a certain schema of a commit message can be enforced. Git hooks for example can be used to make sure that the commit message looks a certain way, has a minimum length, is formatted according to declared standards. As one would do for code-style.
Then they still can just add garbage. But then you have a people problem that no tech will solve
@BatmanAoD Because the commit message is a requirement when committing code. The code comment is sitting there and no one cares whether it'S updated.
And a certain schema of a commit message can be enforced. Git hooks for example can be used to make sure that the commit message looks a certain way, has a minimum length, is formatted according to declared standards. As one would do for code-style.
Then they still can just add garbage. But then you have a people problem that no tech will solve
@BatmanAoD And the commit message *is* documentation. It explains the "Why" making transparent why the code was written the way it is. If the commit message doesn'T reflect that, then you can also use
git commit -m "Fixed issues"
But again: That is then a people problem that no tech will solve!
My point is that "the comments aren't accurate" is also a people problem. And I absolutely disagree that commit messages are "documentation" of anything except the development history.
@BatmanAoD Oh I am absolutely with you that commit messages document the development history.
And there are valid cases for code-comments (I am a strong proponent of them) when they explain why something is solved in this specific way that would otherwise cause confusion when reading the code! But those tend to suffer from entropy ๐