I’m not sure I understand the criticism around documentation in Go, although I’m admittedly not familiar with Javadoc. If you need to document a function parameter beyond its name, most Go authors (this is true of the standard library as well) just add a quick note in the function doc comment. And if you need to add a whole slew of notes for a whole mess of parameters, that’s a good indication that the function may need refactoring. As for the return value, if that’s not obvious, is there a deeper issue with the function itself?
If you need to explain at length what the parameter should conform to, it may need to be sub-typed so it may validate its own complex constraints on construction, or in Go 1.18, it could potentially be generic and constrained.
Would be very interested if the author could clarify the need for structured parameter documentation with some examples.
If you need to explain at length what the parameter should conform to, it may need to be sub-typed so it may validate its own complex constraints on construction, or in Go 1.18, it could potentially be generic and constrained.
Would be very interested if the author could clarify the need for structured parameter documentation with some examples.