We clang-format all code on a directory-by-directory basis. Once everything is more or less proper Mozilla style, we can integrate clang-format into the development workflow.

I don't think this should be a goal. Please link to the discussion that lead to this decision.

Unifying Mozilla style has been discussed on mozilla.dev.platform numerous times. Because people have strong feelings for and against this, these discussions have never led anywhere. Together with bsmedberg (who is the effective owner of C++ code style), we decided to delegate the decision to our distinguished engineers. bz, dbaron, roc, and I got together during the Orlando work week and decided we *should* unify our code style using an automated tool like clang-format. There were some open questions regarding e.g. rebasing over code style changes, but the decision still holds. If you have specific concerns about how a unified code style would negatively affect you, please let us know!

Just like Birunthan said. I am currently working on it. We are currently working on clang-format to address some bugs and difference of behavior with our coding style.

(In reply to Birunthan Mohanathas [:poiru] from comment #2) > Unifying Mozilla style has been discussed on mozilla.dev.platform numerous > times. Because people have strong feelings for and against this, these > discussions have never led anywhere. > > Together with bsmedberg (who is the effective owner of C++ code style), we > decided to delegate the decision to our distinguished engineers. bz, dbaron, > roc, and I got together during the Orlando work week and decided we *should* > unify our code style using an automated tool like clang-format. There were > some open questions regarding e.g. rebasing over code style changes, but the > decision still holds. > > If you have specific concerns about how a unified code style would > negatively affect you, please let us know! I have concerns about it both specifically and in general that I feel were never addressed. What is the correct forum to discuss this?

> What is the correct forum to discuss this? You can expose your concerns here Jeff.

(In reply to Sylvestre Ledru [:sylvestre] from comment #3) > Just like Birunthan said. I am currently working on it. We are currently > working on clang-format to address some bugs and difference of behavior with > our coding style. This isn't actually a well known thing. Perhaps the Orlando decision was communicated in some forum that didn't reach everybody, or didn't sink in. At the least, all the module owners should be formally informed and given a chance to understand the reasons and implications. I don't see them all on the CC-list in this bug, and I'd probably want them all needinfo'd and signing off on this decision, for their module. Doesn't feel like something you would want to railroad "from the top" overriding the module owners. And then you'd want to check with all the managers that are responsible for delivering functionality during the period that these changes would come online. For example, I will oppose any graphics code being touched for "white space" type of changes during 2017 because of the Quantum Render project. Last thing we need is a code churn making things more difficult. Unless this project is also P0 priority, that is.

Here is the ugly script that I am using: --- LIST=$(find . -maxdepth 1 -type d|grep -v "^.$"|grep -v /obj|grep -v "\.deps"|grep -v .hg|grep -v third_par|grep -v "\./\.") echo $LIST for f in $LIST; do echo "$f"; for i in {1..7}; do ./mach clang-format -p $f; done hg revert $( find $f -iname '*.java') || true hg commit -m "reformat of $f" $f done --- Note that I am running clang-format on the directory 7 times because there are things (realignment of comments in /* */) in a single pass.