<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2019 at 8:28 AM Michael de Boer <<a href="mailto:mdeboer@mozilla.com" target="_blank">mdeboer@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Bobby, Victor,<br><div><br><blockquote type="cite"><div>On 8 Jul 2019, at 19:39, Bobby Holley <<a href="mailto:bobbyholley@gmail.com" target="_blank">bobbyholley@gmail.com</a>> wrote:</div><br class="m_7569026539417479213gmail-m_583726688069709608gmail-m_-8972340065132974821Apple-interchange-newline"><div><div dir="ltr"><div>To emphasize: we've made a conscious decision to optimize for off-the-shelf tooling and default configurations. Resources spent maintaining and fiddling with source code formatters are resources not spent on our products. This is why we switched to the well-defined and well-supported Google C++ style (despite nominal availability of "Mozilla" style within clang-format), and why the bar for forking Prettier is going to be high.</div></div></div></blockquote><div><br></div><div>I think forking anything has a high bar in general, through lessons learnt the hard way. But it’d be interesting to learn if you also mean by this to stop trying to improve Prettier through an open collaboration model (probably using PRs on Github) to possibly get it to match our actual JS coding style? (I know about Prettier’s philosophy, but still.)</div></div></div></blockquote><div><br></div><div>As of the reformat, "our actual JS coding style" is whatever Prettier outputs. If someone wants to make the case that we should do engineering work to change that output, they'll need to justify the investment. In that context, impacts to engineering velocity or product quality are going to carry more weight than aesthetics.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div> Perhaps a better new kid on the block will appear in the future? Or a plugin, since it seems like Prettier supports creating pretty powerful ones...</div><div>We’ve done this successfully in the past with ESLint; we’ve made a number of contributions to it over the past couple of years, so that it’d be able to deal with our Mozillian quirks (JSMs, XPCOMisms, etc). Usually tooling for JS is very easy to contribute to and their respective communities are generally very open.</div></div></div></blockquote><div><br></div><div>If the proposed change is specific enough to a Mozilla-ism that it can land in mainline Prettier easily and without controversy, that's a good indicator that the cost is low. Configuration options and plugins have a higher bar, because of the expected increased maintenance burden for us.</div><div><br></div><div>My sense is that the changes people are most concerned about here (multi-line handling) are more fundamental and not something we're going to be eager to change, certainly without more evidence that it causes problems over time.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I know this kind of change isn't easy - we invest a lot in deep familiarity with our code, and having it look radically different one morning can be unsettling. However, I'd encourage anyone grappling with these feelings to give it some time - our experience doing this for C++ suggests that people care less about the specifics of the coding style rules once they can delegate conformance to automated tools.<br></div></div></div></blockquote><div><br></div><div>I hope the gist of this was already common sense for most of us, but thanks for stating it again. I’d like to add that even though the OMGCHANGE reaction is certainly partly here, it doesn’t mean the process to introducing it was perfect and can’t be evaluated for future invasive tree-wide changes.</div><div>For example, I see a very clear pattern of the changes that caused objection from our (quite senior) frontend developers: multi-line if statements and multi-line assignment statements. If these would’ve been exemplified in earlier posts, that would’ve been quite helpful.</div><div><br></div><div>Lastly, I’d like to emphasize the importance of updating our JS style guide to reflect the new Prettier reality, even if tooling solves all these things at one stage or another.</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I'd also like to thank Victor for his careful work to plan, socialize, and execute these changes. It took time and work to get done, but will save everyone countless hours of style nitting going forward.<br></div></div></div></blockquote><div><br></div><div>Yes, thanks Victor and everyone who helped getting this planned out, reviewed and landed!</div><br><blockquote type="cite"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 7:20 AM Victor Porof <<a href="mailto:vporof@mozilla.com" target="_blank">vporof@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 8. Jul 2019, at 15:09, Gijs Kruitbosch <<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>> wrote:<br>
> <br>
> <br>
> On 08/07/2019 12:51, Victor Porof wrote:<br>
>> Compatibility with our previous JS style guide was a non-goal. Instead, consistency, predictability and robust parsing were the primary goals.<br>
> <br>
> I intended to make 2 points in my post:<br>
> <br>
> 1) I don't personally feel that the previous communication was clear about the scale of the change / the fact that compatibility was a non-goal, so I was surprised. That's sort of water under the bridge now, but I hope we'll take that into account for the next type of tree-wide change.<br>
> 2) the end-result is incompatible with our *current* C++ style guide, which continues to be enforced today using clang-format. From that perspective, consistency and predictability is still suboptimal (and arguably that bit is worse than before, as I believe most multiline if statements in JS used the C++ style prior to the reformatting).<br>
> <br>
> What are the plans to deal with (2), if any? Are we intending to update the C++ style to match JS instead?<br>
<br>
There are no plans to interpret Google’s C++ style guide in a way that’s also applicable to JS, or update our C++ style. Consistency between the two languages was a nice to have, but a non-goal in itself.<br>
<br>
High level considerations for consistency were taken into account during planning (e.g. line length, indentation width, etc.). As it turns out, we’ve later found they’re also the only ones enforceable with available tooling.<br>
<br>
> <br>
>> However, as of now, nothing else exists which satisfies some key requirements: consistency, predictability and robust parsing. We’ve analysed prettier, eslint, js-beautify and clang-format, and every single formatting option for each one of them was individually tested against all of m-c beforehand. More information in the FAQ[3].<br>
> I understand it's frustrating that I'm asking this after the fact instead of beforehand. But the FAQ doesn't actually address my point, and it contains less information about the evaluation process you describe than the list of alternatives you've given here.<br>
> <br>
> Assuming that for (2) above we do not intend to change the C++ style, and given that we cannot configure `prettier` to do what we want, what options do we have? Were any of the other options "close" to prettier in terms of the result of the evaluation that was done, to the point that we could use one of those with minor tweaks (presumably accepting some slight regression in terms of performance or some other evaluation criterion)? Or is forking prettier or writing our own equivalent the only option if we want to resolve the dissonance between JS and C++?<br>
<br>
Other tooling was either incapable of properly parsing all of our JS, or unpredictable in terms of output based on the original code, or incapable of automatic reformatting altogether. With regards to performance, the differences are negligible when taking the CI running costs ($) into consideration, which are also too insignificant to offset the differences in human cost (productivity). In terms of technically addressing this: building our own tools to reformat the code, or forking existing ones, aren't engineering programs I consider worth creating. <br>
<br>
As it stands, our C++ and JS style guides are the same on one very valuable metric: we don’t have to think about this while writing code anymore, it’s just a “save” or a commit hook away.<br>
<br>
Victor<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div>
_______________________________________________<br>firefox-dev mailing list<br><a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br></div></blockquote></div><br></div></blockquote></div></div>
</div>