Bugzilla

(In reply to Magnus Melin [:mkmelin] from comment #33)
>
> nit: for documentation, I think indention like this doesn't scale (you add
> one param, and then everything is off). 
> I'd do it like this: (and for return, no -)
> @return {boolean}  true if the request was not redirected
> 
> If it wraps, the next line start would align with e under @return

I definitely agree on avoiding the style where the wrapping doesn't scale.  In that regard I like [this style](https://searchfox.org/mozilla-central/source/dom/test/browser/browser_hasbeforeunload.js#12) found in some m-c files, which I find really readable, and would be simple to write consistently.

I like using "-" for return, if/since we're using it for param, for greater consistency.  It's simpler if you always use it, but I don't feel that strongly about it.

I see you put two spaces between `{boolean}  true`.  We should really document all these conventions and expectations somewhere, especially as they get tighter/more specific than the JSDoc docs, which are pretty loose.  If only Prettier could auto-format JSDoc strings. :)

(In reply to Magnus Melin [:mkmelin] from comment #33)
>
> nit: for documentation, I think indention like this doesn't scale (you add
> one param, and then everything is off). 
> I'd do it like this: (and for return, no -)
> @return {boolean}  true if the request was not redirected
> 
> If it wraps, the next line start would align with e under @return

I definitely agree on avoiding the style where the wrapping doesn't scale.  In that regard I like this style found in some m-c files, which I find really readable, and would be simple to write consistently:

Edit: here's the link: https://searchfox.org/mozilla-central/source/dom/tests/browser/browser_hasbeforeunload.js#12

I like using "-" for return, if/since we're using it for param, for greater consistency.  It's simpler if you always use it, but I don't feel that strongly about it.

I see you put two spaces between `{boolean}  true`.  We should really document all these conventions and expectations somewhere, especially as they get tighter/more specific than the JSDoc docs, which are pretty loose.  If only Prettier could auto-format JSDoc strings. :)

(In reply to Magnus Melin [:mkmelin] from comment #33)
>
> nit: for documentation, I think indention like this doesn't scale (you add
> one param, and then everything is off). 
> I'd do it like this: (and for return, no -)
> @return {boolean}  true if the request was not redirected
> 
> If it wraps, the next line start would align with e under @return

I definitely agree on avoiding the style where the wrapping doesn't scale.  In that regard I like this style found in some m-c files, which I find really readable, and would be simple to write consistently: Edit: here's the link: https://searchfox.org/mozilla-central/source/dom/tests/browser/browser_hasbeforeunload.js#12

I like using "-" for return, if/since we're using it for param, for greater consistency.  It's simpler if you always use it, but I don't feel that strongly about it.

I see you put two spaces between `{boolean}  true`.  We should really document all these conventions and expectations somewhere, especially as they get tighter/more specific than the JSDoc docs, which are pretty loose.  If only Prettier could auto-format JSDoc strings. :)