Как вы отслеживаете авторов кода? [закрыто]

14

Этому меня никогда не учили. Я видел много разных типов авторских стилей. Я кодирую в основном на Java и Python. Мне было интересно, был ли стандартный стиль авторинга или все вольным стилем. Также, если вы ответите, не могли бы вы присоединить стиль, который вы используете, к авторам файлов, которые вы создаете дома или на работе.

Я обычно просто иду

@author garbagecollector
@company garbage inc.
dustyprogrammer
источник
3
Куда человек, который меняет ваш код, ставит свое имя?
JeffO
@ Джефф, где и как это выглядит.
пыльный программист
Нет смысла это делать. Почему вы хотите это сделать?
CodeART

Ответы:

-1

Не совсем уверен, что вы спрашиваете, однако я использую очень строгий стиль:

;==========================================
; Title:  Author Style Sample
; Author: Darknite
; Date:   7 Jan 2011
;==========================================

Стиль вдохновлен ассемблерами.

Я помещаю это в верхнюю часть страниц, которые мне нужны, чтобы «Автор», независимо от того, является ли это классом, текстовым файлом или хранимой процедурой SQL и т. Д.

Темная ночь
источник
Это в соответствии с тем, что я ищу.
пыльный программист
5
-1 Это (которое сильно возрастает при обновлении (и то, и другое и код изменяются разными людьми) эффективно заменяется контролем версий
Майкл Даррант
1
@MichaelDurrant вы забыли закрыть скобки;) в любом случае круто. Я люблю пингвинов
Darknight
4
@ Джорджио Не совсем ... может быть, в файле не осталось ни одной строки исходного автора. Это бессмысленно.
Уилберт
1
@ Уилберт: Конечно, это также зависит от политики команды: при владении общим кодом может быть бессмысленно отслеживать автора файла. При индивидуальном владении кодом важно знать, кто за какие файлы отвечает.
Джорджио
71

Почему ты? это работа системы управления версиями и "винить" :)

Homde
источник
8
управление версиями ftw.
Пол Натан
1
Это имеет больше смысла, если вы думаете об этом как об управлении исходным кодом (SCM), а не как о системе контроля версий (VCS).
Питер Айзентраут
небольшие ограничения, косметические изменения (отступы и т. д.) меняют автора строки ...
Матье М.
4
@Matthieu: Хороший SCM может показать, кто сделал какие изменения с течением времени, а не только последний, кто коснулся этого. Я также могу утверждать, что косметические изменения - это тоже изменения.
grossvogel
1
Этому ответу более 8 лет, и никто не заметил его ограничения? Он применяется только в том случае, если исходный код остается в одной VCS в течение всего срока его службы (или правильно перенесен)! Тем не менее, множество открытых исходных кодов время от времени передаются между различными средами, поэтому информация об авторе может не передаваться, если она не записана непосредственно в исходный код.
Док Браун
11

Мы не занимаемся авторингом в моей компании. Вместо этого мы позволяем нашему управлению версиями справиться с этим.

Каждый раз, когда вы регистрируетесь, он добавляет ваше имя пользователя в список изменений. Если что-то сломано, кто-то может вернуться и посмотреть историю изменений, чтобы увидеть, что изменилось, когда и кто это сделал. Также аккуратно смотреть на график ревизий, чтобы увидеть, как файл развивался с течением времени, кто к нему прикасался, какие проекты из него ветвились.

Проблема, которую я вижу при добавлении тега автора в класс, состоит в том, что со временем вполне вероятно, что над этим классом будет работать более одного разработчика. Обновления и тому подобное. Это дополнительный шаг для обновления этого комментария автора, а дополнительные мелкие шаги часто забываются. Таким образом, он быстро устареет.

Tyanna
источник
10

Я не делаю этого вообще. Я думаю, что на работе у нас есть какой-то шаблон, который вставляется в файлы с названием компании и ИД пользователя, который последний раз изменял файл, но я никогда не обращал на это внимания.

В общем, я не думаю, что действительно важно, как ты это делаешь. Если вы хотите сделать печать на своих файлах, просто выберите подходящий стиль и используйте его.

Адам Лир
источник
6

JavaDoc очень стандартен в сообществе Java:

http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html#@author

@author имя-текст

Добавляет запись «Автор» с указанным именем-текстом в сгенерированные документы, когда используется опция -author. Комментарий документа может содержать несколько @authorтегов. Вы можете указать одно имя для каждого @authorтега или несколько имен для каждого тега. В первом случае Javadoc вставляет запятую (,) и пробел между именами. В последнем случае весь текст просто копируется в сгенерированный документ без разбора. Поэтому используйте несколько имен в строке, если вы хотите использовать локализованный разделитель имен, отличный от запятой.

Лука Маттеис
источник
5

Я думаю, что лучше оставить систему контроля версий.

Tundey
источник
4

Мне нравится функция обвинения в GIT. Вы можете видеть, кто является автором каждого куска / строки кода. Не просто файл.

chiurox
источник
Другие VCS имеют то же самое (хотя часто и не называют «виной»).
Ричард
Я бы -1 это, потому что это специфический GIT. ОП никогда не упоминал GIT. Но, увы, у меня недостаточно представителей, чтобы понизить голос.
Томас Эдинг
2

Если вы работаете над большим проектом со многими участниками, аннотирование каждого файла списком авторов просто не работает. Что вы делаете со списком авторов, когда делите файл на несколько файлов меньшего размера? Вы сохраняете оригинальное имя автора, если полностью переписали код? Вы добавляете свое имя в список авторов, когда исправляете опечатку в комментарии?

Эти вопросы лучше оставить для системы контроля версий.

Но я не совсем против списка авторов. Ведение списка авторов для всего проекта имеет смысл. Если это проект с одним файлом, храните его в этом же файле. Если это более крупный проект, сохраните его в README или в исходном файле верхнего уровня (он же main.c). Но не повторяйте себя, перечисляя авторов в каждом файле.

Рене Саарсоо
источник
1

Мы отслеживаем использование системы контроля версий или путем размещения @authorв коде. Еще один способ сделать это - сказать, что некоторые люди были авторами целых модулей или всей программы. Это побуждает людей воспринимать себя как часть команды, а не как шестеренку в машине, которая отвечает за ровно X функций или строк кода.

Рудольф Олах
источник
0

Я использую комментарии в стиле Doxygen (или иногда KernelDoc) почти для всего. В основном я работаю на C и PHP, где Doxygen довольно популярен.

В большинстве случаев полезно по крайней мере включить следующую информацию:

  • Разрешение (или нет) на его копирование / Авторское право компании или частного лица
  • Имя автора / электронная почта
  • Дата написана
  • Дата последнего изменения

Это должно помочь любому, кто работает с файлом, знать, что у него есть, что он может с ним сделать и к кому он может обратиться за помощью, если он в этом нуждается. Это также говорит им, если они смотрят на что-то 10 лет.

Тим Пост
источник
0

Лично я этого не делаю, потому что это дополнительная документация, которая, как говорили другие, находится в управлении версиями. Но если бы я собирался сделать какой-то фрагмент кода кунг-фу, я, вероятно, был бы готов пойти на то, что моя IDE была способна автоматически генерировать.

Например, используя Delphi 7 с этими полезными установленными CNTools, я печатаю

///a [enter]

и выходит

//<author></author>

тогда я печатаю

///d [enter]

и выходит

 //<date></date>

Я думаю, что это соответствует чему-то, что может подхватить какая-то сторонняя утилита, но что касается меня - у меня есть стандарт, который мне даже не нужно было придумывать и портить.

Питер Тернер
источник