Source changes should include date of change

[Jonathan M Davis]

On Saturday, September 8, 2018 6:35:32 AM MDT tide via Digitalmars-d wrote:
> Dates won't help, if you have a comment with a date that states
> everything under it was modified at that date. What happens when
> there's a split of 3-4 lines between modifications? Just how many
> of these comments are there going to be? This will be unusable,
> adds very little useful information, won't work for past changes
> overwritten changes and deletions.
>
> Just use git, that's what it is designed to do without polluting
> source code with useless comments. If you have the source code,
> there's no reason you won't have the git repo as well. It can all
> be stored and used locally on your own machine.

This also hearkens back to the general issues of comments in code. Many
people like to argue that the code should speak for itself and that if
comments are necessary, there's a problem. I don't think that that's
entirely true - comments can sometimes be vital for explaining the reasons
by a piece of code - but comments not matching the code can be a very real
problem. Every comment that's in the code then needs to be maintained along
with the code, and that often doesn't happen. If dates start getting
sprinkled throughout the code, then there's a good chance that they won't be
up-to-date. And of course, as you point out, it becomes pretty problematic
when the changes aren't all together in a block.

Honestly, arguing for putting dates in the code, because you can't rely on
looking that information up via source control is like arguing that all of
the commit comments should be in the code. It really doesn't make any sense.
This is an area where it really is the source control system's job to deal
with it. git blame (or the equivalent tool for whatever source control
system is being used) is exactly what should be used in this sort of
situation.

- Jonathan M Davis