Rule ForbiddenComment - regexp support

[AndreiZaitcev]

I think that the rule ForbiddenComment is not flexible enough. In my case I'd like to flag every usage of TODO,TODO:,etc... but if it contains a ticket number then it should pass the check.

Noncompliant code:

// TODO remove this code later
fun deprecatedFunction() {}

Compliant code:

// TODO DTK-2019 remove this code later

The main difference for me is that I can disallow usage of TODOs unless a task is tracked in any task system.

Does it make sense to have something like that in Detekt or I should create a custom rule?

[vanniktech]

There's no need to prefix a ticket with TODO. Hence I'd just reference the ticket and leave the todo as is. A ticket implies that there is something missing.

[AndreiZaitcev]

@vanniktech makes sense. I guess I can adjust IDEA to show such comments in the same way it shows TODOs. I'll leave this ticket open if someone has other ideas, but feel free to close it.

[vanniktech]

Yes you can do that. I'm coloring links for instance:

[awesometown]

Maybe this warrants a different issue, but I came across this while looking for similar support for the ForbiddenImport rule. I want to forbid uses of JUnit 4 classes (which are under org.junit) while allowing JUnit 5 imports (which are under org.junit.jupiter) and I couldn't see a way to implement that currently.

Having some means to flag that a particular value in a csv list should be treated as a regex seems like one possibility?

[arturbosch]

That might be a new rule, feel free to open an issue for that. It will need reference solving which is not yet used in detekt though.

[mikekudzin]

Is there any way to suppress suppress ForbiddenComment? We have several distinct todo's we dealt
with and bound them to TD tickets. I got @vanniktech 's point that we do not need "todo" in a such kinda of comments. I almost agree with that. However

1. I worked on a several projects with different teams in different domains and can prove it is a quite common pattern to leave "//TODO TICKET-1234" comments when they agreed upon during a code review stage. It is convenient and has IDE support out of the box.
2. Given (1) I have to force all team members to share the same IDE config and argue with them on why we can't use an approach they used to use for years.

[arturbosch]

I agree with @mikekudzin and @AndreiZaitcev here.
Next to values there should be allowedPatterns to handle ticket numbers.