Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@param with brackets is not supported #72

Closed
davidtorosyan opened this issue Jul 27, 2022 · 6 comments
Closed

@param with brackets is not supported #72

davidtorosyan opened this issue Jul 27, 2022 · 6 comments

Comments

@davidtorosyan
Copy link

@param with brackets is not supported

Before:

/**
 * Summary
 * @param param1 some value
 * @param[param2] another value
 */
fun foo() = Unit

After:

/**
 * Summary
 *
 * @param param1 some value @param[param2] another value
 */
fun foo() = Unit

Using v1.5.4 with default options.

Note that the docs say the following:

To better separate the parameter name from the description, if you prefer, you can enclose the name of the parameter in brackets.

@tnorbye
Copy link
Owner

tnorbye commented Jul 27, 2022

I've fixed this (not yet checked in). But should we have an opinion on whether things should be formatted this way, or just preserve what the user has done? For example, if at least one parameter doc has been written that way, should they all be converted to the same?

@davidtorosyan
Copy link
Author

I'd vote to preserve what the user has done. They're both called out as valid syntax, so I see no reason to prefer one over the other.

@tnorbye
Copy link
Owner

tnorbye commented Jul 27, 2022

My reasoning is that kdoc-formatter (like ktfmt and javaformatter etc) is pretty opinionated -- it decides exactly where there should be newlines, where there shouldn't be, where text must be broken, etc etc. To avoid having style discussion in code reviews, or having individual preferences leak through such that you end up with an inconsistently formatted codebase.

@tnorbye
Copy link
Owner

tnorbye commented Jul 27, 2022

(it also seems like a very little used convention; I grepped for @param[ through a bunch of codebases and the only cases I found were test cases in the Kotlin and Dokka sources :-) )

@davidtorosyan
Copy link
Author

Good point! Changing my vote to converge kdocs on the @param name syntax. :)

tnorbye added a commit that referenced this issue Jul 28, 2022
Misc code cleanup (such as a new FormattingTask object which
passes around state for the formatting job, such that it no
longer has to have the hacky parameter order list in the options
class etc).

Plus 1.5.5 work:
- Fixed the following bugs:
   - #53: The collapse-single-line setting does not work in the IDE
   - #69: Paragraph + list (stability), variation 2
   - #70: Multi-line @link isn't converted if there's a #
   - #71: Make plugin dynamic
   - #72: @param with brackets is not supported
   - A bug where `<p>` paragraphs following a blank line would be
     deleted (without leaving a blank paragraph separator)
- Changed heuristics around optimal or greedy line breaking in list
  items and for KDoc tag and TODO-item paragraph formatting.
- The .editorconfig support is improved. It will now pick up the nearest
  applicable .editorconfig settings for a file, but any options
  explicitly set from the command line will override the .editor config.
   - Also, the "collapse documents that fit on a single line" option,
     instead of just defaulting to true, will now use the default
     specified for the equivalent setting for Java (if set), ensuring a
     more consistent codebase. (You can also set it for Kotlin using
     `ij_kotlin_doc_do_not_wrap_if_one_line`, though that option isn't
     supported in the IDE or by the Kotlin plugin currently.)
- Preliminary support for formatting line comments and block comments
  (enabled via new flags, `--include-line-comments` and
  `--include-block-comments`.)
- Misc IDE plugin improvements
- `<pre>` tags are converted into KDoc preformatted blocks
@tnorbye
Copy link
Owner

tnorbye commented Jul 28, 2022

This is fixed in 1.5.5 (and it does convert to the canonical format as discussed).

@tnorbye tnorbye closed this as completed Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants