-
-
Notifications
You must be signed in to change notification settings - Fork 307
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
docs: add inline documentation #91
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the inline documentation is useful just for the methods exported by this library. Internal methods should have their naming clear enough
By other stuff I meant the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Including SearchResult
would be great, yeah.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the inline documentation is pretty redundant to me. Example:
export interface Lyra<S extends PropertiesSchema> extends Data<S> {
/**
* The default language analyzer in use.
*/
defaultLanguage: Language;
/**
* The structure of documents stored in the database.
*/
schema: S;
edge: boolean;
}
You don't need to add inline documentation to everything, just mention unclear fields.
For instance:
/**
* The maximum [levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance)
* between the term and the searchable property.
*/
tolerance?: number;
is a great addition. As said previously, I'd keep just the inline doc for exported functions + unclear fields (tolerance
)
I have added docs only for the four major functions. Once the writing style gets a green flag I would be happy to document all the other stuff.