your opinion: adding rules to restrict "Move" code moving scope?


Before posting a request, I'd like to gather some comments and ideas
about this.

-


The problem :
-



When refactoring code, IDEA would let you move everything everywhere.
You could, f.ex, move a method
from the
.(main source-path),
to a
.(test code-path).

Sometimes, this is very wrong.
When juggling with 4+ sourcepaths in the "Choose a source path" target
dialog, this error is easy to make.
And if you were to build a jar from the .(Main Output path)
only, it would miss the needed methods that you moved erroneously in the
.(Test output path). This happened to me.

Below are a few suggested rules. A subset of those can be easily
implemented.

-


Example : a 3-module, 6-sourcepath project,
-



see illustration attached :



comments on the diagram :
green arrows = methods move is allowed
red arrow = methods move is forbidden.

(this is one example of customized rules. Yours could be different).

green : allowed,
because you may have to modify the production code
to make it easier to test.
red : forbidden
because the production code may not depend on the test code.

green : allowed,
because you may "enrich" the library module,

red : forbidden
because the library module can not depend on the main module.

red : forbidden
because the "test framework" module is 'read-only'.

etc...


-


Code inspections
-


If you can't move a method from the Main/source to the lib2/text, you
cannot obviously write code in main/source that depends on lib2/text.
A few code inspections - Dave, are you there - could check for theses
"wrong dependencies" violations.

Ex. of inspections :

  • "Main code depends on its test code"

  • "Test code depends on other modules test code"

  • "library module depends on master module"

...


What do you think?

Alain



Attachment(s):
MoveRefactoringRestrictions.png
4 comments


Alain,

Sorry I hadn't seen this one earlier. I had been thinking about creating "dependency" oriented inspections, but am wary about creating inspections that (I feel) should be enforced by the modules system. Since it looks like there won't be any such enforcement in Aurora, I'll add your suggestions to my list. However, I'm wondering what the issue is with "Test code depends on other modules test code". It would seem perfectly reasonable to have a, for example, a abstract base test case in one module and have it subclassed as a concrete test case in another (dependent) module. Is there something else that I'm missing, here?

On your main issue, I do think the move refactoring should be cognizant of module-system dependency/library/testing declarations, if it can be done without adversely affecting performance. I'm less certain about the ability to add rules, seeing that as more in the realm of inspections.

--Dave

0

Dave

> On your main issue, I do think the move refactoring should be
> cognizant of module-system dependency/library/testing declarations,
> if it can be done without adversely affecting performance. I'm less
> certain about the ability to add rules, seeing that as more in the
realm
> of inspections.

1/
The simplest and most useful "rules" are actually binary values, ie. a
checkbox in the ui.
Example:
"Don't allow moving to another module"
"Tests code may only use this module code"
"Tests code may only use this module, or depending modules' code"

2/
Though I agree they would be most useful as inspection rules,
I feel hardcoding these rules in the editor, would avoid the annoyance
of having to fix the error later.
I don't think it would hamper performances.
It's also easier, and more comfortable, when moving a method,
- to locate a class in a smaller classes set.
- to locate a source tree in a smaller directories set.


> I had been thinking about creating "dependency" oriented inspections,
> but am wary about creating inspections that (I feel) should be
enforced
> by the modules system. Since it looks like there won't be any such
enforcement
> in Aurora, I'll add your suggestions to my list.


As written above, in 2/, I prefer preventing a code location "error", at
writing time, than fixing it later. For this very reason, I think this
feature working field should be the editor.
Anyway, I'd be grateful if you decide to climb this mountain, and offer
us more inspection rules. They would be invaluable, where refactoring
existing code, or when partioning 1 module into many.


> However, I'm wondering what the issue is with "Test code depends on
> other modules test code". It would seem perfectly reasonable to have
> a, for example, a abstract base test case in one module and have it
subclassed
> as a concrete test case in another (dependent) module. Is there
something
> else that I'm missing, here?

1/
This is an option, so you'd enable it only when it makes sense.

2/
Real life example : while coding the camouflage plugin, I felt the need
for a more powerful testFramework than IDEA's one, so I extended it, to
cover FoldRegions. I made this a separate and independent module
"testFrameworkExtension".
This module - src and test - currently lives only in this project, but I
doesn't depend on the other project modules. Should this be the case, it
would prevent me from reusing it for another project. That's what I want
to avoid.


Alain

0

All I want regarding moving between modules is for IDEA to:

1. Guess which module I want it in, based on which module owns the given package
2. Show a tree instead of that terrible listbox, for selecting which sourcepath to move to

0

Keith Lea wrote:

>All I want regarding moving between modules is for IDEA to:

>

Some people wrote about their 20-module project.
Don't you think the extra filtering offered by - optional - rules like :
"Move methods/classes only to the same module"
would make our life easier, even when we have only 3 or 4 modules.
Reminder: this "rule" is module based => you can turn it off when it
makes no sense.

Alain

0

Please sign in to leave a comment.