Здравствуйте, AlexGin, Вы писали:
AG>Вот, например, добавил строку кода (в исходный файл) и написал комментарий:
Зачем растекаться мысью по древу? Просто:
// added 25.08.2023
смысл понятен и коротко или вообще ничего не писать, если предполагается хранить код только в одном репозитории, система контроля версий сама подскажет когда added.
Здравствуйте, AlexGin, Вы писали:
AG>// This line have been added 25.08.2023
(Кстати, has, а не have, но это типичная ошибка для нас — не концентрируемся на этом.)
Это предполагает состояние в настоящем времени, которое порождено действиями в прошлом и выражено через них. А теперь — что будет, если строка будет изменена? Состояние изменилось, комментарий потерял актуальность, и теперь надо "This line had been added 25.08.2023, has been updated 31.08.2023"? Ну и накойхер?
[UPD: я обсуждая это сам забыл что present perfect с датой не сочетается! вот она сила внушения]
AG>Я отдаю предпочтение первому варианту (действие было в определенном прошлом, строка добавлена в код).
Здравствуйте, Dym On, Вы писали:
DO>Зачем растекаться мысью по древу? Просто: DO>// added 25.08.2023 DO>смысл понятен и коротко или вообще ничего не писать, если предполагается хранить код только в одном репозитории, система контроля версий сама подскажет когда added.
Ну предположим, был коммит 20-го и 30-го числа, а такой комментарий — даст больше ясности
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, AlexGin, Вы писали:
AG>>// This line have been added 25.08.2023
N>(Кстати, has, а не have, но это типичная ошибка для нас — не концентрируемся на этом.) N>Это предполагает состояние в настоящем времени, которое порождено действиями в прошлом и выражено через них. А теперь — что будет, если строка будет изменена? Состояние изменилось, комментарий потерял актуальность, и теперь надо "This line had been added 25.08.2023, has been updated 31.08.2023"? Ну и накойхер?
AG>>Я отдаю предпочтение первому варианту (действие было в определенном прошлом, строка добавлена в код).
N>Да. Или как рядом посоветовали — просто added...
ИМХО вероятность, что дойдёт до "updated" как-бы небольшая.
Я так понимаю, что в пределах между git commit-ами эта вероятность маленькая.
Ну а после коммита — уже ориентироваться проще
Здравствуйте, Alekzander, Вы писали:
DO>>Зачем растекаться мысью по древу? Просто: DO>>// added 25.08.2023
A>Ну, всё-таки, // Line added 25.08.23. Не function, не scope.
Здравствуйте, Lazytech, Вы писали:
L>Здравствуйте, AlexGin, Вы писали:
AG>>Но вопрос — как бы остался: как правильно?
L>Формат даты, скажем так, не американский. Я бы использовал "обратный" формат YYYY-MM-DD (2023-08-25).
Точки вместо слэшей подчёркивают, что американский формат не при делах.
Здравствуйте, Lazytech, Вы писали:
L>Здравствуйте, netch80, Вы писали:
N>>Точки вместо слэшей подчёркивают, что американский формат не при делах.
L>Тем не менее, в некоторых случаях могут понять неправильно.
Я думаю, на любое данное любого формата найдётся, кто поймёт его неправильно
Но если их устраивает 23-й месяц — их проблемы.
Здравствуйте, netch80, Вы писали:
N>Но если их устраивает 23-й месяц — их проблемы.
Да, в данном случае, надо полагать, даже американцам будет догадаться нетрудно. Но во многих других случаях, а именно когда день месяца не превышает 12, могут и не угадать.
Most Common Date Formats in English
The most common way for writing dates in English is to use day/month/year format (also denoted as DD/MM/YYYY). For example, if you were writing the date for the fifth of January , 2022, you would write it as 05/01/22.
However, there are also other ways to write dates in the English language. Americans use the month/day/year format – again, in a purely numerical form. This way, the same date, January fifth, would be written as 01/05/2022.
Another way to write the date in English is to add the day of the week first, followed by the day and then the month. So, the same date would be written as Friday, 5 January 2022.
And finally, you can use the international standard for writing dates in English – write the year first, followed by the month and then the day (also known as YYYY/MM/DD format). This way, the same date would be written as 2022/01/05.
Note that the numerical format of date writing is generally used informally or when there’s limited space. If you choose the all-numeric date format, there are always two slashes or hyphens to separate the parts of the date – one between the day and month, and another one between the month and year.
Здравствуйте, Lazytech, Вы писали:
L>Да, в данном случае, надо полагать, даже американцам будет догадаться нетрудно. Но во многих других случаях, а именно когда день месяца не превышает 12, могут и не угадать.
Можно, конечно, заморочится, и писать буквами, типа 11-SEP-2001, я так иногда делаю, если знаю, что дату могут читать из разных частей света. Но в данном случае, имхо, избыточно.
Здравствуйте, netch80, Вы писали:
AG>>// This line have been added 25.08.2023
N>(Кстати, has, а не have, но это типичная ошибка для нас — не концентрируемся на этом.)
Там две "типичные" ошибки: has/have и дата с has/have
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, netch80, Вы писали:
AG>>>// This line have been added 25.08.2023
N>>(Кстати, has, а не have, но это типичная ошибка для нас — не концентрируемся на этом.)
P>Там две "типичные" ошибки: has/have и дата с has/have
Здравствуйте, AlexGin, Вы писали:
AG>Но вопрос — как бы остался: как правильно?
AG>Я отдаю предпочтение первому варианту (действие было в определенном прошлом, строка добавлена в код).
have been образует вариант страдательного причастия, ЕМНИП. Можно вообще без вспомогательных глаголов. Просто added at/on
Формат даты зависит от страны. Ошибка практически исключается при использовании технического формата YYYY-MM-DD.
AG>Да, я в курсе грамматических правил:
Здравствуйте, AlexGin, Вы писали:
DO>>смысл понятен и коротко или вообще ничего не писать, если предполагается хранить код только в одном репозитории, система контроля версий сама подскажет когда added. AG>Ну предположим, был коммит 20-го и 30-го числа, а такой комментарий — даст больше ясности
Не даст. Оба коммита можно посмотреть по отдельности и посмотреть что там менялось.
А коммент — это отложенный вопрос что делать следующему, кто изменит эту строку? Нужно ли поменять дату в "was addd xx.xx.xxxx"? Но это будет некорректно, ведь изменяющий не меняет факта добавления строки, а только меняет ее часть.
Получается, ему надо добавить к комментарию пункт что "и была обновлена yy.yy.yyyy". Потому что ничего не добавлять — это тоже путаница, читающий код решит что эта строка так и действует с xx.xx.xxxx, а по факту она имела существенное изменение позже.
А что делать 3му, который опять меняет? Менять дату обновления в этом важном комментарии (два человека уже его пилили), или добавить вторую дату обновления? "this line was added xxxxxx was updated yyyyyyyy and updated zzzzzzzz"?
И все это дублирует информацию в системе контроля версий.
(и хорошо если дублирует, а если там отличается? 4й меняющий не в нес правки в комментарий, а 5й внес, и вроде читая код видишь историю этой строки, а нет, не все видишь).
