[FEATURE] generate synthetic @param and @return for @Getter/@Setter

[mirabilos]

As a follow-up to https://github.com/rzwitserloot/lombok/issues/132#issuecomment-759115434 I’d like to have an option (ideally in lombok.config because this is really project‑ or at least module-wide) in which @param and @return in auto-generated getters and setters are synthetically generated instead of the user having to add it to the Javadoc of the slot/attribute/property and it being copied from there. (The text that is there, of course, still needs to be copied, as it will be the whole description.)

Rationale: @param and @return are invalid javadoc on slots and IntelliJ removes them on reindenting the file.

(I’ve also filed an issue against the IntelliJ Lombok plugin to make them support it, but having this would be preferable… less red tape to type.)

[mirabilos]

Suggestion for the synthetic data (open for improvements):

Type varname; will generate

• @param {@link Type} varname
• @return {@link Type} varname

Not as sure the type needs to be in @param but I customarily add it to @return and would prefer it there. This way is symmetric and easily synthesised and will not cause major upheaval but good cross-linking.

[rspilker]

I'm not sure I understand your request correctly. But I think you mean that delombok should transform

@Getter @Setter
class Foo {
    private int bar;
}

to

class Foo {
    private int bar;

    /**
     * @return int bar
     * /
    public int getBar() {
        return this.bar;
    }

    /**
     * @param int bar
     * /
    public void setBar(int bar) {
        this.bar = bar;
    }
}

if the field has no description provided by the programmer.

If that is what you propose, I can guarantee that both Reinier and I are going to deny this request, because we're not going to help in spreading this nonsense practice of providing documentation without adding value to the user.

However, if I misunderstood your proposal, please add a "before" and an "after" image of your suggestion, like I did in this comment.

[mirabilos]

Roel Spilker dixit:

if the field has no description provived by the programmer.

This is about the cases where the field has a description provided by the programmer.

However, if I misunderstood your proposal, please add a "before" and an "after" image of your suggestion, like I did in this comment.

Taking from your example:

Before: /**

• Lorem ipsum und so weiter. */ @Getter private int bar;

After: private int bar;

/**
 * Lorem ipsum und so weiter.
 *
 * @return int bar
 * /
public int getBar() {
    return this.bar;
}

/**
 * Lorem ipsum und so weiter.
 *
 * @param int bar
 * /
public void setBar(int bar) {
    this.bar = bar;
}

Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[rspilker]

How about we would support @ret and @par in the javadoc on fields to solve your removal problem instead? That would be a few minutes work.

[mirabilos]

Roel Spilker dixit:

How about we would support @ret and @par in the javadoc on fields to solve your removal problem instead?

Hmm, I’d have to see whether IntelliJ flags/removes them.

But I’d really prefer the synthetic ones, at least as an option; in almost all cases I’ve got any javadoc on slots with automatic getters and setters, writing them out does not make any sense at all, and it’s just red tape.

Since Lombok can already do that in the case where there is no javadoc, extending it should be easy enough.

I was only trying adding explicit @param and @return because it did not do so, and was having a hard time making it not sound redundant or generated…

bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

[mirabilos]

Roel Spilker dixit:

How about we would support @ret and @par in the javadoc on fields to solve your removal problem instead?

No, IntelliJ also flags and removes these. For those users who want to go the way with manually adding them, I’d prefer the original tags then (once IDEA-259347 is solved).

As for this feature request, it’s about users who don’t want to write @ret(urn) and @par(am) in the property javadoc, as explained in the previous eMail.

bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg