Still about improving the official documentation.
|modified content, my style – snapshot for jQuery $( String, Object )
|official content, my style – snapshot for jQuery $( String, Object )
|official content & style – snapshot for jQuery $( String, Object )
Functionality VS function
As an example of something that needs a rewrite take the $ function, which accepts many inputs and mostly does one of two things: either selects a group of elements into a DOM (possibly all of them), or creates a group of elements from scratch.
In the official documentation these two functionalities are mixed up in the filecard with one string argument, whereas the selection functionality with a string argument is split among two filecards, depending on wether there is only one argument for the string or also a second argument for the context. In case of one argument, the functionality does not change because a default value is used for the context.
The signature of a function
A very good thing in the official documentation is the use of type declarations for functions and arguments. Javascript is loosely typed and this is just a handy trick. I think I found a problem related to how much it is used.
The name of a function cannot be adapted in the documentation to reflect its type, so a declaration like Array<Element> get() makes a lot of sense. A different approach is needed for an argument name, which certainly can get a new name in the documentation. For the sake of readers, the same pseudo types should be used as much as possible for arguments as well. In fact, if an argument can get different types without changing the functionality of the function, then it’s much better to use a generic Object type and add a comment than it is to use a more specifiic Element type just because it is the most frequent use of that argument. In the former case the reader gets a hint at a nuance to whatch out, in the latter they need to carefully read the filecard to get the nuance.
The pseudo signature of a function can be augmented also with default values for optional arguments, like other languages do. This improves the readability a bit more, because less words are needed in the documentation, as it is a visual device.
An id for each functionality
Having each functionality documented in its own filecard, a unique identifier for referencing them is then needed. For example, see also the code in 2 could be a short comment of an example in a filecard, where the reader can be made aware of watchouts related to that code. The longer see also the code in ‘jQuery $( String, Object )’ is more informative but would be harder to add in the source of jQuery and to create an hyperlink in the documentation. To implement: longer form automatically built from id
The benefits of an id for each functionality go well beyond that. When speaking or writing about jQuery functions, the use of an id could simplify the reference, though something like calling 32 from 154 causes 9 to hang should definitely be avoided, and for posterity is to be preferred something like (this purely fictitious) calling toggle (32) from oneunload (154) causes serialize (9) to hang (using Rev:123)
For a working sample, I’ve added an id attribute to the method element of the documentation XML. It’s now a decimal number, starting from 1, which I’ve assigned to the most used function of jQuery: jQuery $( String, Object ). For making straighforward the referencing in the documentation XML and hence in the js sources, you simply have to wrap a grave accent (`) around the id of a function, like see also the code in `2`. This works inside the description of a function or example, and inside the comment of an example.
