code quality alarms.

hi.

Here is an other idea for helping with code quality.

What if IDEA checked certain set rules(like always these would be configurable) ad alerted you as soon as you broke them. I see this as a hybrid of Intentions and Inspections.

For Example: you have a project which contains some api/framework packages and implementation packages, or it is made up of separate blackbox components and you want to make sure no action, refactoring creates an unwanted dependency. I would really like it if somehow this was checked I was alerted as soon as I did something that broke this rule.

These would be specially useful when doing some refactoring and your going to touch a lot of classes and would like to make sure you don't break this rule.

The key idea here is that you are alerted to a problem right away while you are within the scope of the problem. I often find that with code inspections I am afraid to apply the inspection suggestions because I often don't have time to assess all the suggestions being made.

Florian Hehlen

ps: hope no one is minding all my posts this evening... I am feeling specially inspired!

8 comments
Comment actions Permalink

What if IDEA checked certain set rules(like always
these would be configurable) ad alerted you as soon
as you broke them. I see this as a hybrid of
Intentions and Inspections.


I don't think doing this kind of thing on-the-fly is feasible. IDEA current inspections (together with InspectionGadgets and MetricsReloaded) provide more than enough functionality for you to gauge and control your code quality -- just make sure you run a full inspection on your project every now and then (when JetBrains forks fix the standalone inspection you could do that in your daily build script).

ps: hope no one is minding all my posts this
evening... I am feeling specially inspired!


It's friday after all. I don't expect you to be productive on a friday :) Guess why I'm also posting so much this afternoon?

0
Comment actions Permalink

> I don't think doing this kind of thing on-the-fly is
> feasible. IDEA current inspections (together with
> InspectionGadgets and MetricsReloaded) provide more
> than enough functionality for you to gauge and
> control your code quality -- just make sure you run a
> full inspection on your project every now and then
> (when JetBrains forks fix the standalone inspection
> you could do that in your daily build script).

First of all I wouldn't want everything that code inspections does, done on the fly. That surely would not be feasible. But I think that there are things like introduced dependencies that can be hard to fix even after one day of work. I have some extremely productive days (when I will write... say 200-500 lines of code) and fixing some problems after the fact can be time consuming if in the heat of the moment you did not realize your were not respecting some intended design or pattern.

the other reason for needing this is that some projects I have worked on have a very big code base where I am more interested in not introducing new problems than in fixing the 1000's of existing inspection problems. I do not have the privilege of working in an all IDEA team where everyone regularly does code inspections.

Florian

0
Comment actions Permalink

Isn't this approximately what the new dependency view rules stuff does. I know it's available as an inspection, and remember it was supposed to be available as an on-line warning. It won't warn you that a refactoring will break a rule (a worthwhile Tracker request), but it should do most everything else you describe, once JetBrains is finished with it.

--Dave

0
Comment actions Permalink

Dave Griffith wrote:

Isn't this approximately what the new dependency view rules stuff does. I know it's available as an inspection, and remember it was supposed to be available as an on-line warning. It won't warn you that a refactoring will break a rule (a worthwhile Tracker request), but it should do most everything else you describe, once JetBrains is finished with it.

--Dave


It actually mostly done so you can already benefit from it. Look at "Illegal package dependencies" inspection under
General group in Errors configuration. The only thing missing there is what dependencies to be considered as invalid.
Those rules can be configured via any launch of Dependency Analysis.

--
Maxim Shafirov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

hi.

I guess I will have to try these new features and get back to all of you. I am still stuck on 4.0.3 because of some memory bug when ever I try using the latest builds.

Maybe it will be all I wished for :)

Florian

0
Comment actions Permalink

Florian Hehlen wrote:

First of all I wouldn't want everything that code inspections does, done on the fly. That surely would not be feasible. But I think that there are things like introduced dependencies that can be hard to fix even after one day of work. I have some extremely productive days (when I will write... say 200-500 lines of code) and fixing some problems after the fact can be time consuming if in the heat of the moment you did not realize your were not respecting some intended design or pattern.

the other reason for needing this is that some projects I have worked on have a very big code base where I am more interested in not introducing new problems than in fixing the 1000's of existing inspection problems. I do not have the privilege of working in an all IDEA team where everyone regularly does code inspections.

Florian

So, like a set of project (or module) rules that are tested before
(and/or after) each major code change? Sounds interesting. Would be very
useful for legacy projects where there are a lot of undocumented and
unenforced assumptions. You could add rules as you discover them so that
you don't make the same mistakes twice. One possible drawback I can see
is that it would make legacy code even more inflexible; it could 'alert'
you against making a change that would actually be good for the code.
However, I guess you could ignore the alerts and anyway, the programmer
is in theory intelligent enough to know when the rules apply and when
they don't.

0
Comment actions Permalink

> interesting. Would be very
> useful for legacy projects where there are a lot of
> undocumented and
> unenforced assumptions. You could add rules as you
> discover them so that
> you don't make the same mistakes twice. One possible

That's exactly it. I currently work in a EJB project of 1500+ classes. The code has suffered a lot from much patching and quick fixes. And like in all shops there is little/no time to fix these problems.

So what I am interested in is, although I cannot always fix many issues with dependencies, with scope, etc... I want to refrain as much as possible from adding new problems. And since I am new to the project and do not know the whole history of the project it's often easy to create more circular dependencies in the code if you don't drill down into the code. So, on the best days I find these dependencies early and work around them... other times when I find such issue it either means a lot of rework to remove the dependency or ends up being a new bad dependency in the code.

> drawback I can see
> is that it would make legacy code even more
> inflexible; it could 'alert'
> you against making a change that would actually be
> good for the code.

I think I want to know when I am breaking boundaries like:
-package scope
-changing visibility of a method. ex: changing from package to protected or public
-using code from separate source directories

I don't specifically need IDEA to suggest anything or to stop me from doing an action... mainly I want to be warned.

That being said, I have finally managed to get build 2026 to work and looked at the "Analyze dependencies" tool. It seems to be part of what I need. But, with a lot of legacy code it creates a lot of noise that is hard to sort through. Maybe as the feature matures I will see more clearly if it helps me.

later,
Florian

0
Comment actions Permalink

Florian Hehlen wrote:

I think I want to know when I am breaking boundaries like:
-package scope
-changing visibility of a method. ex: changing from package to protected or public
-using code from separate source directories

I don't specifically need IDEA to suggest anything or to stop me from doing an action... mainly I want to be warned.

That being said, I have finally managed to get build 2026 to work and looked at the "Analyze dependencies" tool. It seems to be part of what I need. But, with a lot of legacy code it creates a lot of noise that is hard to sort through. Maybe as the feature matures I will see more clearly if it helps me.

later,
Florian


Florian, I think this is a good candidate for a feature request. It
would enhance the adaptability of IDEA to large and/or legacy projects.
I previously worked on a large project which had many bad design flaws
which I simply could not change (due to time and priorities), and it
took a LONG time to get anything done for fear of breaking some arcane
rule. This may also be possible to do as a plugin similar to Inspection
Gadgets (I don't know enough about Open API to say for sure). Also, you
might look into the various rule-engines that are out there. There's
even a JSR (http://www.jcp.org/en/jsr/detail?id=94). I don't know if
it's relevant, just an idea.
And lastly, the Analyze Dependencies feature is quite new and in need of
feedback. If you have a chance, please try it and give some feedback for
how it could be improved for your needs. Perhaps you may need to better
isolate its analysis, or ignore certain cases or something. Thanks.
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.