Bug 549876 - [Feature Request] mark code as temporary for easy clean up / delete
Summary: [Feature Request] mark code as temporary for easy clean up / delete
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-08 05:22 EDT by Florian Krammel CLA
Modified: 2019-08-16 05:41 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Krammel CLA 2019-08-08 05:22:18 EDT
Hallo,

my request is quite simple. Maybe it's not the right way to write clean code, but in the real world you'll get code with "test code" or code for outputs only. 

For example:

main(){
    // productive code
    fancyImageLib.doMagic(image);

    //useless code for testing
    fancyImageLib.show(image);
    System.out.println(image.getMetadata());
    log.print("now I'm testing");
    fancyImageLib.saveR("r.jpg");
    fancyImageLib.saveB("b.jpg");
    fancyImageLib.saveG("g.jpg");

    myTestFunctionWithUselessStuffAndAlotOfLines();  //no unit test

    .... a lot of useless code ...



}

One line is productive code and >8 lines "useless". If I'll get 10.000 lines of code it'll take time to clean this code and the code shrinks to 5.000 lines of productive code. (Please don't discuss code quality).

To prevent growing crappy code a feature to mark this code as "test" or multiple categories would be a benefit.

requested features:

- mark the code block as comment with a tag like //TODO 
    e. g. 
    //BeginTestCode
    ... code() ...
    //EndTestCode
    (prefered for interoperatibility with other IDE's)
- mark the code block like break points
- automatic deactivate or/and delete this marked code
- go trough single code blocks with deactivate / delete like search and replace

Thanks for reading
Comment 1 Roland Grunberg CLA 2019-08-08 09:50:56 EDT
As a workaround for this, I try and insert my 'useless code for testing' into conditional breakpoints that are guaranteed to not return true. This way they get executed, but the break point isn't hit, and there's no risk of the changes accidentally making their way into version control.

This is similar to what CDT is doing with "Dynamic printfs" I believe though implementation may be different.
Comment 2 Florian Krammel CLA 2019-08-08 10:57:03 EDT
Yes this is a workaround. But if I'm not the author of that code I have to check the code an add the breakpoints. If the author can tag it with a comment and eclipse can handle this, it's a simple push on a button. This is what I want.
Comment 3 Rolf Theunissen CLA 2019-08-08 15:07:03 EDT
The feature that you are requesting is called 'regions'. Mostly they are used for custom folding. They are not supported by Eclipse out of the box. 

See the following question: https://stackoverflow.com/questions/2344524/java-equivalent-to-region-in-c-sharp

Assigning to JDT.
Comment 4 Roland Grunberg CLA 2019-08-08 15:27:07 EDT
Apparently https://github.com/stefaneidelloth/EclipseFolding is mentioned as supporting regions. Maybe some investigation is needed into whether it could be updated to work on latest Eclipse.
Comment 5 Florian Krammel CLA 2019-08-08 17:20:23 EDT
Regions don't change the code? Regions for folding hide the code in the editor, but it'll be still executed. 

This feature should comment the code out, remove or reactivate it.

Before:

main(){

    run()
    //region
    print("hello world")  <----
    //end region

}

Push "deactivate" button:


main(){

    run()
    //region
    // print("hello world")    <----
    //end region

}

Push "activate":

main(){

    run()
    //region
    print("hello world")    <----
    //end region

}



Maybe it's a extension of regions.
Comment 6 Mickael Istria CLA 2019-08-12 11:22:12 EDT
IMO, starting to build some conventions in the code, that are not Java standard, and that are supposed to affect the code execution is an anti-pattern: this will be hardly usable, not standard, not portable, would encourage to messier code... This seems to require a lot of effort to implement for a feature that isn't clearly nice to have in the general case and to improve the domain.
Comment 7 Florian Krammel CLA 2019-08-16 05:41:11 EDT
(In reply to Mickael Istria from comment #6)
> IMO, starting to build some conventions in the code, that are not Java
> standard 
That's not right. This feature should convert code into comments with special tags like task tags. This part of the feature exists already. The problem is I have to check the code at this tag. This is not a non standard convention for java. Every IDE must be able to handle that. Another problem is, if I'm using task tags it'll flood the task list with these tags.

The other way is to set someting like breakpoints. But this requires that the author of the code uses the same IDE (eclipse). Sometimes they're using a simple notepad. But this alternative isn't a "new convention", too. 

This feature should simple comment-out these code block and simple comment-in by one click.  Comments are Java compliant.  

> and that are supposed to affect the code execution is an
> anti-pattern: 
This is the point where discussion about code quality begins. For example you'll get code from a scientist, e. g. a biologist with some java skills, and the code is ugly. 10000 lines with 5000 useless code, distributed between the production code. I think this code is an anti-pattern by principle ;-)  To extract the production code is time consuming. I can't refuse the code, but I can instruct the author to mark these code. This feature exsists already, too. It's a combination of task tags and search and replace between the tags. I want to combine this with some automation. IMO automation is no anti-pattern.

> this will be hardly usable, not standard, not portable, 
I don't agree. That's just comments and the extension is eclipse only.

> would encourage to messier code... 
This is a problem by personal attitude, not a toolset problem. I requested this feature to handle messier code, to refactor it. This sounds like a discussion about a knife. You can use it as tool or weapon. 

>This seems to require a lot of effort to
> implement for a feature that isn't clearly nice to have in the general case
> and to improve the domain.

Sure in a clean environment with educated developers this feature may be useless. But I'm one preson and I know a lot of other developers who will benefit from this feature. 

Ist this really a lot of effort?

- task tags exists - its a "filter" to exclude this tags from task list
- regex between begin and end tags
- search-and-replace every line with itself, with or without two slashes