JIRA/TFS marking comments... in code.
-
I know I've posted about this before, but it's gotten worse since then. It's become a policy to mark lines that were changed, according to their TFS/JIRA numbers.
I argued that blame tools with the source control could let us know exactly what a code change was related to, as long as commit comments contained the TFS task number, which is already a process standard we follow.
This ends up looking like this
method(int b) { // TFS-123123 Start a = 5; c = 10; // TFS-123123 End return a + b; }
Apparently, it's very important that people that don't have access to our source control tools can trace back errors, because the delivery teams still look at code when trying to research an issue before they escalate to us.
But apparently that wasn't enough.
And now this is becoming popular
method(int b) { // TFS-123123 Start // a = 3; // c = 8; // a should be 5, and c should be 10; a = 5; c = 10; // TFS-123123 End return a + b; }
Please... make it stop.
-
My coworker keeps putting issue #'s in code. I don't know why.
-
-
@xaade said in JIRA/TFS marking comments... in code.:
And now this is becoming popular
Somebody doesn't understand how source control systems work... (FYI: No jury of your peers will find you guilty!)
-
@xaade The situation calls for this pattern:
method(int b) { // TFS-123123 Start a = 5; // TFS-312312 Start c = 10; // TFS-123123 End b = 6; // TFS-312312 End return a + b + c; }
-
@xaade said in JIRA/TFS marking comments... in code.:
Apparently, it's very important that people that don't have access to our source control tools can trace back errors, because the delivery teams still look at code when trying to research an issue before they escalate to us.
It's a sucker's bet, I know, but what are the chances they don't actually take advantage of this benefit and just escalate issues to you anyways?
-
@Adynathos said in JIRA/TFS marking comments... in code.:
@xaade The situation calls for this pattern:
method(int b) { // TFS-123123 Start // TFS-456789 Start a = 6; // TFS-456789 End // TFS-312312 Start c = 10; // TFS-123123 End // TFS-456789 Start b = 5; // TFS-456789 End // TFS-312312 End return a + b + c; }
-
You only think that was a joke.
I have a header that's 27 lines, and only 13 lines of method declarations.
The rest are start stop comments.
And there's this one.
// apple start a // pen start b // apple end c // pen end
-
@dcon
Based on the second code block in the OP it should be more likemethod(int b) { // TFS-123123 Start // a = 3; // c = 7; // a should be 4, and c should be 5 // TFS-456789 Start // a = 4; // c = 5 // a should be 6, and c should be 8 a = 6; // TFS-456789 End // TFS-312312 Start // c = 8; // c should be 10, and we should set b to 4 c = 10; // TFS-123123 End // TFS-456789 Start // b = 4; // did I say 4? I meant 5 b = 5; // TFS-456789 End // TFS-312312 End return a + b + c; }
-
@xaade Maybe you should make a plugin for your IDE that will hide all comments starting with "TFS-" :)
-
@dcon said in JIRA/TFS marking comments... in code.:
FYI: No jury of your peers will find you guilty!
His peers sound like a bunch of idiots.
-
@Bort said in JIRA/TFS marking comments... in code.:
@dcon said in JIRA/TFS marking comments... in code.:
FYI: No jury of your peers will find you guilty!
His peers sound like a bunch of idiots.
We can help with cleansing the gene pool...
-
@Adynathos said in JIRA/TFS marking comments... in code.:
@xaade Maybe you should make a plugin for your IDE that will hide all comments starting with "TFS-" :)
Not a bad idea.... actually.
But, it's kinda sad that they're now doubling (or more) the size of the delta by leaving the old code in there.
-
@hungrier said in JIRA/TFS marking comments... in code.:
@dcon
Based on the second code block in the OP it should be more likemethod(int b) { // TFS-123123 Start // a = 3; // c = 7; // a should be 4, and c should be 5 // TFS-456789 Start // a = 4; // c = 5 // a should be 6, and c should be 8 a = 6; // TFS-456789 End // TFS-312312 Start // c = 8; // c should be 10, and we should set b to 4 c = 10; // TFS-123123 End // TFS-456789 Start // b = 4; // did I say 4? I meant 5 b = 5; // TFS-456789 End // TFS-312312 End return a + b + c; }
:(
I found code like that before too.
It's more rare, but it happens.
-
@xaade This means war!
https://youtu.be/4XNr-BQgpd0
Escalate the madness. Start committing changes to “fix” the values in comments. Or raising tickets to ask for the values to be fixed.
-
@dangeRuss said in JIRA/TFS marking comments... in code.:
My coworker keeps putting issue #'s in code. I don't know why.
I sometimes do that as well, for example when I add a weird if statement to fix a corner case. Would you prefer 10-line comments that summarize the rationale for some weird check?
-
@asdf If it's some code that otherwise doesn't make sense, then yeah.
-
@xaade Haha, I'll give you $100 to sneak in a
// bell end
.
-
@xaade said in JIRA/TFS marking comments... in code.:
If it's some code that otherwise doesn't make sense, then yeah.
So you'd rather have a really long multi-line inline comment than a reference to a ticket in which the problem is discussed in detail?
I'd rather read the JIRA discussion, which is nicely formatted HTML, but to each his own, I guess.
-
@asdf said in JIRA/TFS marking comments... in code.:
I'd rather read the JIRA discussion
I'm sorry, you can't because your administration forgot to pay the bill for JIRA this month…
-
@asdf said in JIRA/TFS marking comments... in code.:
So you'd rather have a really long multi-line inline comment than a reference to a ticket in which the problem is discussed in detail?
Absolutely. Don't make us lazy programmers have to jump thru another hoop to go find the info! And if you ever change bug systems, well, you're just screwed then. (Yes, I've worked in places like that. And source control had changed too, so the history wasn't there either.)
-
@dcon said in JIRA/TFS marking comments... in code.:
@asdf said in JIRA/TFS marking comments... in code.:
So you'd rather have a really long multi-line inline comment than a reference to a ticket in which the problem is discussed in detail?
Absolutely. Don't make us lazy programmers have to jump thru another hoop to go find the info! And if you ever change bug systems, well, you're just screwed then. (Yes, I've worked in places like that. And source control had changed too, so the history wasn't there either.)
-
@dcon said in JIRA/TFS marking comments... in code.:
if you ever change bug systems
Guess what happens if source code gets transferred from one organisation to another?
-
@dkf said in JIRA/TFS marking comments... in code.:
@dcon said in JIRA/TFS marking comments... in code.:
if you ever change bug systems
Guess what happens if source code gets transferred from one organisation to another?
Half the files are lost?
-
@dcon said in JIRA/TFS marking comments... in code.:
Half the files are lost?
Well, typically (and yes, I've seen it happen a few times) you lose the documentation, the issue database (or even if you don't, they all get renumbered), and often much of the commit history. Occasionally, you only get a zip of the current state of the code. Most often of all, you get nothing at all for ages because the guy who was supposed to do the transfer on their end got laid off at the same time, and so someone has to figure out how to get into their computer and actually extract the state of the code. I've yet to see anyone transfer a truly complete set of build instructions with any code release, not even when using systems that are supposed to automate all that (such as Maven or Gradle).
Getting the full code, the issues, the docs and the real build instructions… well, I guess it might happen occasionally. Never seen it though.
-
@asdf said in JIRA/TFS marking comments... in code.:
So you'd rather have a really long multi-line inline comment than a reference to a ticket in which the problem is discussed in detail?
No.
But at least something indicating "this is on purpose."
Again, this is in a world where there isn't a comment for every commit, and you actually use the source control to figure it out when you really need to know. That's why blame and other tools exist.
-
@xaade said in JIRA/TFS marking comments... in code.:
But at least something indicating "this is on purpose."
That's what I do. Example code:
// make sure foo is usable, see #PROJ-1234 if (foo.stale()) { foo.update(); }
(Assuming it's not obvious why you have to call
update()
there. If it's obvious, there's no need to link to the ticket which provides a long explanation of the corner case.)
-
@asdf Yeah, even with commit comments, it's useful to link issues in comments to tell 'the full story'. But not by default.
-
@asdf If it is TFS with Git you can use a Git hook so it will match up the JIRA issue number and even puts the code change into jira comments, requires some wanky with python though.
Tbh this can be more effort that it is worth IMHO. I've always used Jira ticket number and what files I have changed and why.
-
@asdf said in JIRA/TFS marking comments... in code.:
@xaade said in JIRA/TFS marking comments... in code.:
But at least something indicating "this is on purpose."
That's what I do. Example code:
// make sure foo is usable, see #PROJ-1234 if (foo.stale()) { foo.update(); }
(Assuming it's not obvious why you have to call
update()
there. If it's obvious, there's no need to link to the ticket which provides a long explanation of the corner case.)Yes, that is also reasonable.
The point is that you should avoid wrap every single code change with comments about which JIRA ticket it belongs to, because you have source control, and that's your tool for linking it.
Your comment is there to make unobvious code linked to an issue so no one changes it back at a glance.
-
@dangeRuss said in JIRA/TFS marking comments... in code.:
My coworker keeps putting issue #'s in code. I don't know why.
I saw something like that once. It was in ABAP code that was written by the guys over at SAP Germany themselves. (If you have a SAP system, you can use SE37 to view the source code to basically anything.)
Maybe the SAP stuff doesn't have the concept of "version control"?
-
This of course all buttumes you don't get an "enthusiastic" product/project manager who deletes done tickets as "they were just cluttering up JIRA".
-
@Arantor said in JIRA/TFS marking comments... in code.:
This of course all buttumes you don't get an "enthusiastic" product/project manager who deletes done tickets as "they were just cluttering up JIRA".
-
@dangeRuss said in JIRA/TFS marking comments... in code.:
My coworker keeps putting issue #'s in code.
It's not too obnoxious provided access to the issue is available. The advantage with having the numbers in (comments in) the code as opposed to checkin comments is that it means that the issue number is visible when just reading the code. You don't need to switch the IDE to code archæology mode.
-
@dkf said in JIRA/TFS marking comments... in code.:
You don't need to switch the IDE to code archæology mode.
Also, a git blame might still not show you the issue number if the code was changed, moved or reformatted in the meantime.
-
@xaade said in JIRA/TFS marking comments... in code.:
according to their TFS/JIRA numbers.
That sounds like your setup might be even more convoluted than ours.
Our setup is that we have TFS, including tasks, where we deliver the code to the customer (and generally code directly on), but additional Jira, which mostly mirrors the TFS and is used for time tracking (time tracking in TFS sucks) and notes that don't fit the formal structure required of the TFS tasks.
Is your setup even more crazy?
-
@asdf said in JIRA/TFS marking comments... in code.:
Also, a git blame might still not show you the issue number if…
That's what the pickaxe is for.
-
@Arantor said in JIRA/TFS marking comments... in code.:
deletes done tickets
Sounds like someone's asking for a permissions tweak
-
@Bulb said in JIRA/TFS marking comments... in code.:
@xaade said in JIRA/TFS marking comments... in code.:
according to their TFS/JIRA numbers.
That sounds like your setup might be even more convoluted than ours.
Our setup is that we have TFS, including tasks, where we deliver the code to the customer (and generally code directly on), but additional Jira, which mostly mirrors the TFS and is used for time tracking (time tracking in TFS sucks) and notes that don't fit the formal structure required of the TFS tasks.
Is your setup even more crazy?
Tfs for time tracking and task tracking.
JIRA is for external issue reporting and tracking.
-
@Yamikuronue unfortunately that particular clown was the JIRA admin.
-
@Arantor said in JIRA/TFS marking comments... in code.:
@Yamikuronue unfortunately that particular clown was the JIRA admin.
@Yamikuronue said in JIRA/TFS marking comments... in code.:
Sounds like someone's asking for a permissions tweak
I don't see how the former precludes the latter.
-
@Maciejasjmj when the person who needs a permissions tweak is the ONLY person with the keys to the permissions cupboard...
-
@xaade said in JIRA/TFS marking comments... in code.:
Tfs for time tracking and task tracking.
JIRA is for external issue reporting and tracking.I am disappoint. That, like, even makes sense (it would be better to use JIRA for both though; this is just wasting money on TFS license).
-
@Yamikuronue said:
@Arantor said in JIRA/TFS marking comments... in code.:
deletes done tickets
Sounds like someone's asking for a permissions tweak
In such a case, I would generally recommend tweaking his permissions by hauling that GAU-8 out of your back pocket and "tickling" him with it. You do have one of those, right? (If not, you can borrow mine.)
-
@Yamikuronue said in JIRA/TFS marking comments... in code.:
Sounds like someone's asking for a
permissions tweakreason to update his/her resumeFTFY
-
So what happens if a given changeset consists of multiple, separate blocks? Would we see a
TFS-111 begin
andTFS-111 end
for each block?
-
@HardwareGeek said in JIRA/TFS marking comments... in code.:
@Yamikuronue said in JIRA/TFS marking comments... in code.:
Sounds like someone's asking for a
permissions tweakreason to update his/her resumeFTFY
Said person no longer with company after a series of mistakes.
-
@Groaner said in JIRA/TFS marking comments... in code.:
So what happens if a given changeset consists of multiple, separate blocks? Would we see a TFS-111 begin and TFS-111 end for each block?
I'd expect so. It'd be the stupidest option, given that some types of change can touch a lot of code in minor ways, so that's what someone who has no idea of why it is a bad idea would pick. And enforce because to do otherwise might indicate that they made a bad decision, which is inconceivable!
-
At IFS this shit is mandatory for ALL code changes. And yes, they have (their own shitty version of) source control. And yes, after four or five updates you have lots of start/end comments mixed with each other.
They don't care. And they flag you in code review if you didn't place the start/end markers exactly.Thank god we fired that customer long ago.
Don't get me started on their shitty programming language, programming environment, programming standards and database layer. :puke:
-
@Bulb said in JIRA/TFS marking comments... in code.:
Is your setup even more crazy?
- TFS for version control
- Jira for raising issues, time tracking and keeping track of progress
- An internal helpdesk application to duplicate what Jira does in a much less intuitive intervace
- I also need to send out a weekly spreadsheet to the business detailing what I've been working on so they can see progress and I can meet my "communicates with people occasionally" performance goal
- Until recently, all Jira tickets needed a spreadsheet attached with details on the issue, resolution and technical notes. That's now done in the Jira ticket instead, since someone started learning how to modify the workflows