I'll upload a patch set to fix these two very soon. However, I'm not sure whether my corrections are the best way to go about it.

I've changed some

function wfFoo() { // Bad function
    $bar = 5;
    ...

to

function wfFoo() {
    // Bad function

    $bar = 5;
    ...

and I've broken some empty function definitions from

function wfBC() {}

to

function wfBC() {
}

Comments?

Change 218889 had a related patch set uploaded (by Polybuildr):
Fix braces code style

https://gerrit.wikimedia.org/r/218889

Change 218889 merged by jenkins-bot:
Fix braces code style

https://gerrit.wikimedia.org/r/218889

• https://gerrit.wikimedia.org/r/218889 (branch master): MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10)

The patch has been merged, but I'm still not sure if it was the best way. Leaving this task open for now, waiting for responses.

Seems fine to me.

function wfBC() {
}

LGTM

@Legoktm, @bd808, any responses to @Nikerabbit's comment?

In T102805#1377392, @Nikerabbit wrote:

I dispute the sniff "Closing brace must be on a line by itself" as it prevents doing one-line anonymous functions, such as function ( $file ) use ( $dir ) { return "$dir/$file"; } in https://gerrit.wikimedia.org/r/#/c/217320/1..2/MessageGroups.php. I also don't like forcing body-less functions to two lines.

Single line anonymous functions sound like a contradiction of existing style guide information:

Do not write "blocks" as a single-line. They reduce the readability of the code by moving important statements away from the left margin, where the reader is looking for them. Remember that making code shorter doesn't make it simpler. The goal of coding style is to communicate effectively with humans, not to fit computer-readable text into a small space. -- Manual:Coding_conventions#Braceless_control_structures via Manual:Coding_conventions/PHP#Brace_placement

In general, coding conventions for multi-developer projects (and especially ones with automated validation) are a compromise. Nobody will like all of the rules. I personally find the extra whitespace inside parens rule to be useless and annoying, but it's the project convention so I follow it. As long as the enforced rules that are being introduced don't require large scale change of the codebase (i.e. they fit the large majority of the existing manually enforced code style) I don't see a problem.