<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><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><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><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>