For example
...\api\src\main\java\io\opentelemetry\common\ReadableKeyValuePairs.java:28: warning: no @return
int size();
^
or
...\api\src\main\java\io\opentelemetry\common\Labels.java:86: warning: no @param for value4
public static Labels of(
Can you assigne to me?
Not sure it makes sense to write javadoc for obvious params or return values... Is there any profit in such warnings?
+1 to changing the defaults to not require param / return, we can make sure javadoc is useful through code review. But I wouldn't block if anyone else feels strongly about them. FWIW, if I had to choose between the style of the JDK or @trustin I'll generally side with the later :)
Personally I'm especially annoyed by having to write (and read!) @return docs that are literally copy and paste from the summary section.
100% agreed with loosening up the javadoc requirements a bit. Duplicated useless javadoc doesn't help anyone.
You now even require javadoc for benchmarks??
You now even require javadoc for benchmarks??
I don't think it was intentional...just got swept up in the madness.
+1 to this. We should do (later) a pass to remove things that may be annoying to new contributors.
@Oberon00 Can we close this? I think this is done now with #1494
I think so!
Most helpful comment
+1 to changing the defaults to not require param / return, we can make sure javadoc is useful through code review. But I wouldn't block if anyone else feels strongly about them. FWIW, if I had to choose between the style of the JDK or @trustin I'll generally side with the later :)