Can R# help tie code elements to outside tracking systems in comments?

There's an interesting post here about how IDE's could theoretically use comments to help link code back to outside tracking systems like test cases, requirements, bug bases, etc.

http://www.artima.com/weblogs/viewpost.jsp?thread=231684

"

  • Fine grained versioning control at the programming element - let me know who authored or last modified a my function/class, also function level undo

  • Test-driven development support - show/hide the tests, and let me know whether it has been changed since it was last tested

  • Requirements binding - what requirement a feature is connected to

  • Model binding - what component of the model this feature connected to

  • Bug/work-item tracking - what bugs or work-items are associated with this program element

"

Can R# do any of this? What about the plugin architecture of R#, can it support writing plugins along these lines? I've only looked at the plugin architecture briefly when it was first released and at the time the documentation was very light.

Thanks,

Sam

2 comments
Comment actions Permalink

Samuel Neff wrote:

There's an interesting post here about how IDE's could theoretically
use comments to help link code back to outside tracking systems like
test cases, requirements, bug bases, etc.

http://www.artima.com/weblogs/viewpost.jsp?thread=231684

"

  • Fine grained versioning control at the programming element -

let me know who authored or last modified a my function/class, also
function level undo * Test-driven development support - show/hide
the tests, and let me know whether it has been changed since it was
last tested * Requirements binding - what requirement a feature
is connected to * Model binding - what component of the model
this feature connected to * Bug/work-item tracking - what bugs or
work-items are associated with this program element "

Can R# do any of this? What about the plugin architecture of R#, can
it support writing plugins along these lines? I've only looked at
the plugin architecture briefly when it was first released and at the
time the documentation was very light.

Thanks,

Sam


Documentation of OpenAPI is till !poor!, i wish that jetbrains could
write good OpenAPI documentation with lots of examples.

--

0
Comment actions Permalink

This is just my personal opinion, but while doing this kind of thing is great (and is already done all the time in lots of environments, in case you might not have known) doing this kind of thing through comments is asinine. This is an issue to be addressed automatically by your version control and change management (issue tracking / bug tracking / whatever you want to call it) systems. Get them talking. If either or both can't be made to talk to the other, replace them.

Once they are talking, you're basically there, and if you want to be more advanced then it wouldn't take much to hook into this information via code in order to attribute specific code elements to issues via automation of some combination of diff and/or blame or what have you.

Comments are a code smell, and this kind of comment would really stink. ;)

0

Please sign in to leave a comment.