this post was submitted on 10 Oct 2024
3 points (63.6% liked)
JetBrains
204 readers
11 users here now
A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/
Related Communities
- !aqua@programming.dev
- !clion@programming.dev
- !datagrip@programming.dev
- !dataspell@programming.dev
- !fleet@programming.dev
- !goland@programming.dev
- !intellij@programming.dev
- !phpstorm@programming.dev
- !pycharm@programming.dev
- !rider@programming.dev
- !rubymine@programming.dev
- !rustrover@programming.dev
- !webstorm@programming.dev
Copyright ยฉ 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@BatmanAoD Having done code archeology for over a decade now I can assure you that the issue with all the information that you need to understand why something was done has been discarded just shortly before due to moving to a different platform... Or something similar.
In any case: Having all the relevant data in one place and not scattered is a huge advantage.
@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 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.