Good code is red - Not a critical any more ?

I always believed that these kind of bugs - 'Good code is red' - are critical. And I had the feeling that you in JetBrains treat them like this.
So I was really surprised to find that my bug will be fixed only in 'Selena': http://www.jetbrains.net/jira/browse/IDEADEV-12951

This upset me from some reasons:
1. This bug is stopper: If I tell programmers to ignore one 'red' code - how they will know which one to ignore.
2. This bug was introduced in later builds of 6.x - so why it won't be fixed in 6.x ?
3. We just all upgrade our licenses from 4.5/5.x to 6. I can't ask my managers to upgrade to 7.x

Please consider fixing this in 6.x.
If you are already planning to do this then I'm apologizing for this post.

Regards
Boaz

11 comments
Comment actions Permalink

Boaz,

The rule of thumb when fixing bugs is that only those fixes, that are guaranteed not to cause regressions are promoted to minor release branch. Unfortunately this is not the case with your bug. I'm sorry for this, but anyway I don't feel this bug is frequent enough to undermine your trust in IDEA analysis.

Eugene.

P.S. I don't think crossposting makes you sound louder:)

0
Comment actions Permalink

I'll side with Boaz on this one. Any "good code is red" kind of bug is absolutely critical. Add up a couple of these bugs, and even if they don't show up that often, they have a very serious consequence: the user will stop trusting IDEA's code analysis, eventully rendering the whole concept useless.

That's what happened to me with IDEA's JSP/HTML/CSS editor. It shows so many false positives that I might as well use another editor for this (I'm using TextMate). If I have to sort through errors to find out which ones are actually errors, and which one's are false positives, I don't need highlighting at all.

So, please reconsider this. I won't complain about the JSP/HTML errors anymore, this is a lost battle -- but don't let the Java editor turn out the same.

0
Comment actions Permalink

Agreed.

This 'code red' stuff is the biggest drag on productivity.

0
Comment actions Permalink

Perhaps it is too risky for a minor dot release, but in general I agree that every known issue that is either "Good code is red" or "Bad code is green" should be addressed. I believe I just saw a "Bad code is green" issue get shuffled off to the near-to-death-but-not-dead-yet backlog today.

0
Comment actions Permalink

The bug moved to backlog was not about incompilable project being flagged as good. It is about our strategy to report bug in a file that actually has the problem. IDEA is smarter than javac, that's all. It is really impossible to copy ALL javac behavior, and neither Eclipse nor IDEA tries to be 100% javac compatible (we are JLS compatible, and these bugs are indeed of high priority to us).

That said, I would really like to backport my fix to Boaz' bug, but I'm afraid this would be too risky (it is potential to performance degradation, which is another high prioroty issue to us)

0
Comment actions Permalink

Sounds good, Eugene. Yep, IDEA is much smarter than javac as far as flagging issues goes.

0
Comment actions Permalink

I agree with Boaz and Marcus. "good code is red" and "bad code is green" are serious obstacles to our smooth work with IntelliJ.
Especially in an environment like ours were we have a large group of programmer and we use IntelliJ to enforce a unified style. Telling people - you should watch for these errors and warnings works very well, but once you have to qualify that: be aware that a, b, and c are known bugs and you should ignore them (or check then yourself) this does not work anymore.
I have not hit yet on the specific example Boaz' code shows but I remember very badly such bugs you had in the past and my wish for their quick resolution.

0
Comment actions Permalink

I agree with Boaz and Marcus. "good code is red" and "bad code is green" are serious obstacles to our smooth work with IntelliJ.
Especially in an environment like ours were we have a large group of programmer and we use IntelliJ to enforce a unified style. Telling people - you should watch for these errors and warnings works very well, but once you have to qualify that: be aware that a, b, and c are known bugs and you should ignore them (or check then yourself) this does not work anymore.
I have not hit yet on the specific example Boaz' code shows but I remember very badly such bugs you had in the past and my wish for their quick resolution.

0
Comment actions Permalink

Hi Eugene.

There is something I'm missing here.
I'm using IntelliJ since version 4.0. So it is a fact that I wrote this
piece of code using IntelliJ. Another fact is that when I wrote it, it
flagged as 'good' code. I know I can't proof I wrote it using IntelliJ 6.0,
but I'm almost sure I wrote it using EAP versions of IntelliJ 6.0.
So, this bug is regression or not ?

Regards
Boaz


"Eugene Vigdorchik" <no_reply@jetbrains.com> wrote in message
news:20068901.1169051332233.JavaMail.itn@is.intellij.net...

The bug moved to backlog was not about incompilable project being flagged
as good. It is about our strategy to report bug in a file that actually
has the problem. IDEA is smarter than javac, that's all. It is really
impossible to copy ALL javac behavior, and neither Eclipse nor IDEA tries
to be 100% javac compatible (we are JLS compatible, and these bugs are
indeed of high priority to us).

>

That said, I would really like to backport my fix to Boaz' bug, but I'm
afraid this would be too risky (it is potential to performance
degradation, which is another high prioroty issue to us)



0
Comment actions Permalink

I also join those that support Boaz. This issue is far beyond a minor bug. Besides that fact that I had something that was working fine in previous releases and now it isn't, this issue has an educational bad effect on the programmers in my team. I expect every programmer to leave his code clean. The motto is "clean is green". Now when I encounter "red code", I have to check out why. When the alert is false this enquiry is not a trivial one.
Make the extra effort and fix this bug in 6.x. I don't think that my motivation to purchase an upgrade should for having bug fixes. This should be included in the price that I already paid.

0

Please sign in to leave a comment.