Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.

If some code is added or changed it is very simple to add the date of change in a comment.

// Date: Date1, Date2, Date3, ....

Anything below a was changed at those dates.



Why not also add a link to the git hub patch or bugzilla or whatever?

On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.
>
> If some code is added or changed it is very simple to add the date of change in a comment.
>
> // Date: Date1, Date2, Date3, ....
>
> Anything below a was changed at those dates.
>
>
>
> Why not also add a link to the git hub patch or bugzilla or whatever?

Git is the tool that's used to manage changes, including viewing the changes.

A lot of dev time has gone into it and it works really well.

Some ad hoc comment system in source code to point out changes will never be as good.

Just Use Git!

On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
> On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
>> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.
>>
>> If some code is added or changed it is very simple to add the date of change in a comment.
>>
>> // Date: Date1, Date2, Date3, ....
>>
>> Anything below a was changed at those dates.
>>
>>
>>
>> Why not also add a link to the git hub patch or bugzilla or whatever?
>
> Git is the tool that's used to manage changes, including viewing the changes.
>
> A lot of dev time has gone into it and it works really well.
>
> Some ad hoc comment system in source code to point out changes will never be as good.
>
> Just Use Git!

Um, I didn't say don't use Git!

Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself.

The fact of the matter is that dates in source code will help when git is not available and one only has the source code.

On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo wrote:
> On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
>> On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
>>> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.
>>>
>>> If some code is added or changed it is very simple to add the date of change in a comment.
>>>
>>> // Date: Date1, Date2, Date3, ....
>>>
>>> Anything below a was changed at those dates.
>>>
>>>
>>>
>>> Why not also add a link to the git hub patch or bugzilla or whatever?
>>
>> Git is the tool that's used to manage changes, including viewing the changes.
>>
>> A lot of dev time has gone into it and it works really well.
>>
>> Some ad hoc comment system in source code to point out changes will never be as good.
>>
>> Just Use Git!
>
> Um, I didn't say don't use Git!
>
> Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself.
>
> The fact of the matter is that dates in source code will help when git is not available and one only has the source code.

Comments showing last modified date are pure noise. The code is what gets executed and what you should focus on. If you need history look at git log. The date is generally useless and code deltas are what you want and this is why VCS tools exist.

The only caveat to all that is a copyright statement, which should include the year. But this is orthogonal sprinkling dates throughout your code base.

But if you really want to do this more power to you, it is your code. Set up a hook in your fav. editor that inserts a date comment each time you enter ";" followed by the return key.

Bye,
Norm

On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo wrote:
> On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
>> On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
>>> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.
>>>
>>> If some code is added or changed it is very simple to add the date of change in a comment.
>>>
>>> // Date: Date1, Date2, Date3, ....
>>>
>>> Anything below a was changed at those dates.
>>>
>>>
>>>
>>> Why not also add a link to the git hub patch or bugzilla or whatever?
>>
>> Git is the tool that's used to manage changes, including viewing the changes.
>>
>> A lot of dev time has gone into it and it works really well.
>>
>> Some ad hoc comment system in source code to point out changes will never be as good.
>>
>> Just Use Git!
>
> Um, I didn't say don't use Git!
>
> Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself.
>
> The fact of the matter is that dates in source code will help when git is not available and one only has the source code.

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.

On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo wrote:
> Um, I didn't say don't use Git!
>
> Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself.
>
> The fact of the matter is that dates in source code will help when git is not available and one only has the source code.

Git does a better job of tracking history automatically than anyone could ever realistically do by hand. So not only would date comments be useless duplication of work, they'd be useless duplication of inferior quality to the original.

It would be like keeping a horse at your house at all times, in case your car breaks down. Even if it's occasionally useful, it is not worth the constant maintenance costs of feeding the horse, cleaning the stable, etc.

If your car breaks down, you find a way to get it fixed. If git isn't available to you, you find a way to make it available.

On Saturday, 8 September 2018 at 12:36:01 UTC, Paul Backus wrote:
> On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo wrote:
>> Um, I didn't say don't use Git!
>>
>> Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself.
>>
>> The fact of the matter is that dates in source code will help when git is not available and one only has the source code.
>
> Git does a better job of tracking history automatically than anyone could ever realistically do by hand. So not only would date comments be useless duplication of work, they'd be useless duplication of inferior quality to the original.
>
> It would be like keeping a horse at your house at all times, in case your car breaks down. Even if it's occasionally useful, it is not worth the constant maintenance costs of feeding the horse, cleaning the stable, etc.
>
> If your car breaks down, you find a way to get it fixed. If git isn't available to you, you find a way to make it available.

Interactive programs like GitExtension show exactly the the date of each line with the git blame view.
Visual Studio Code with the D extension also shows the commit info when hovering over the code.
There are a lot of nice way to use the git info to get the date of the line.

Dates in the comments are utterly useless. They are imo even counter productive. The information has not bearing with the actual code.
There is no point in putting dates in the comments when the code is managed by git.

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

On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote:
> Some ad hoc comment system in source code to point out changes will never be as good.
>
> Just Use Git!

I'd agree for implementation changes, but *interface* changes should be not just in the comment, but in a doc comment. Ddoc specifically has a "History:" section for this (and adrdox also supports "Since:").

So if you add a function, say when it was added, either a release version number or the date it was released. When you change function arguments, show it too.

Then if someone is looking at code and looking it up in the documentation, they can see that like it called "foo!int" and it is "History: added support for int in version 2.089, Sept 2018." and then be like "oh that's why it is erroring, my thing is version 2.088"

On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote:
> Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should.

What problem did you encounter where you had trouble getting the information you needed with git blame, where a source code comment listing change dates would help?

> Why not also add a link to the git hub patch

Because that's a lot of work to replicate something git already does.

> or bugzilla or whatever?

Currently, some code in phobos does reference issues on the dlang bugzilla. The common categories for this include:

* Explaining why we want things to work this way, if that requires more than a couple sentences of explanation
* Pointing out what problem this is a workaround for
* Pointing out which past problem motivated this unittest

Things that help you understand the code as it currently is.

Is there some situation you've encountered in the past where that kind of comment wasn't enough?