Good afternoon.
Without further ado, please go read the Deno Style Guide
Especially if you don't use deno, and don't intend to try it out any time soon.
If, for no apparent reason, you want to read some excerpts with emojis in between, here are some of the many gems in that little document:
- A function that is part of the public API takes 0-2 required arguments, plus (if necessary) an options object (so max 3 total).
Optional parameters should generally go into the options object.
The 'options' argument is the only argument that is a regular 'Object'.
Other arguments can be objects, but they must be distinguishable from a 'plain' Object at runtime, by having either:
- a distinguishing prototype (e.g.
Array
,Map
,Date
,class MyThing
)- a well-known symbol property (e.g. an iterable with
Symbol.iterator
).This allows the API to evolve in a backwards compatible way, even when the position of the options object changes.
Meta-programming is discouraged. Including the use of Proxy.
Be explicit even when it means more code.
Do not document function arguments unless they are non-obvious in their intent (though if they are non-obvious, the API should be reconsidered anyways). Therefore @param should generally not be used.
Code examples should not contain additional comments. It is already inside a comment. If it needs further comments it isn't a good example.
If you want to steal it for your project, this is where the markdown lives.
Disclaimer: The author is not affiliated with the deno project or its authors. Copyright of all images belongs to their respective owners.
Have fun!
Top comments (2)
Thank you for the remainder, I actually should read it ASAP.
Seems that the links have changed Deno Style Guide (markdown)
Thank you, I updated the link. (was previously web.archive.org/web/20190502004324..., a rendering of web.archive.org/web/20200108070705...).
At the time of writing it still contains all of the spicy quotes.