Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A API reference doc: best practices for describing opaque parameters?

This surely depends on the specific tool that you are using. The only tool that I am familiar with that meets your description is Javadoc, so I want to be cautious not to make assumption about how ...

posted 11y ago by Jay‭  ·  last activity 5y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T03:00:03Z (about 5 years ago)
Source: https://writers.stackexchange.com/a/8488
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by user avatar Jay‭ · 2019-12-08T03:00:03Z (about 5 years ago)
This surely depends on the specific tool that you are using. The only tool that I am familiar with that meets your description is Javadoc, so I want to be cautious not to make assumption about how other tools might work.

But with Javadoc, there is a built-in way to describe parameters. The whole point of Javadoc is to have a consistent way to document an API, so I think that given the feature is there, you should use it.

Personally, nine times out of ten I put absolutely nothing in the parameter descriptions. The code itself gives the data type, and I give the parameters meaningful names, and then in the general description block I describe how they interact.

When there is something interesting to be said about a particular parameter, I put it into those parameter descriptions where it belongs. Usually this means that the name is not adequate to describe what it really is. Like I might specify that "String customerName" can be either the name of a person or of a company, or that "int delta" is the signed change in the voltage over the specified time period.

In general, when the tool gives you "slots" to put specific data and then an area for a general description. I put as much in the specific slots as I can, to take advantage of the features that are there.

I would definitely NOT create fake classes or functions solely for the purpose of eliminating redundancy in the docs. That violates my sense of esthetics to clutter up code just to fool the documentation generator into producing what I want. In real life, what I usually do in such cases is nothing. I fully document the parameters or whatever the first time I use them, and then just don't on further occurrences. Okay, that's sloppy. But Javadoc does give you the feature that you can link to the documentation for another class or function. (Umm, is it "@link"? I forget, it's been a while since I used it.) To take a simple case, if you have an overloaded function or similar case where parameters with the same meaning are used in multiple functions, I think the right thing to do is to fully document them in the function with the longest parameter list and then link from the other functions to that one, with some explanatory text like "See foobar() for description of the parameters". I say the function with the longest parameter list meaning that if there is one function that has all or most of these parameters, document them all there, in one place, and then link there, rather than documenting one here and one there.

#1: Imported from external source by user avatar System‭ · 2013-07-24T13:26:46Z (over 11 years ago)
Original score: 2