How the Vanilla dev staff decides important issues

Linc

inside joke background: the history of lord brackos

Tim

DaazKu

So many bytes used for nothing...
So many keystrokes done for nothing...
That makes me sad

Tim

I ordered us some more bytes from Office Depot, we should be good.

R_J

Good to see that you take your time for such important decisions

whu606

And a new poetic form, the DaazKu...

x00

I agree with the decision.

The most important thing with coding standards is consistency and clarity.

x00

I think the current standards/guidelines should be expanded e.g spacing decision like (· representing spaces)

if·([condition])·{

}

if·([long condition]
····&&·[long condition])·{

}

Do we do?

namedFunction(·$var1,·'some string');

namedFunction(·$var1,·$var1·);

$namedArray['some string'];

$namedArray[·$var1·];

if·(·$var1·) {

}

like some frameworks

Or

namedFunction($var1,·'some string');

namedFunction($var1,·$var1);

$namedArray['some string'];

$namedArray[$var1];

if·($var1) {

}

Like others.

Both wordpress and phpBB have guidelines to this degree and I have found it has helped quite a bit. I would check out this guideline not to copy exactly, but to give you an idea.

If I know I can bare than in main and also set up some git filters.

Even the current standard have cause some confusion or differences, and there is still a legacy from the old style.

Even the use of strings when it is ok to double quotes or single. Not so much for performance, but consistency and reduce the chance of stupid errors, and germinally be readable.

Linc

@x00 The latter style - no padding inside brackets & parenthesis. I'm amenable to a doc PR that adds that in a reasonable place if it isn't in there.

We have no specific guidelines on double vs single quotes currently. Generally, I favor single quotes for short non-language strings (like array keys) and double for longer stuff like UI text. I think Vanilla trends toward this but it's pretty fuzzy, and I'm not sure how to write that as a standard or whether the council must be convened for ratification.

x00

I'm in favour of this style of concatenation

'some string' . $someVar . 'another string';

not

'some string'.$someVar.'another string';

any operator too should have space either side.

x00

the edit button also make doc PRs easier.

x00

I recommend git filters that trim trailing spaces and blank lines.

x00

given that language text can have formatString bracket in it like My {Name}. I think language strings should be single not double.

Also the current locales are single.

Linc

@x00 said:
I'm in favour of this style of concatenation

Unfortunately, we've standardized on the latter (no spaces).

@x00 said:
any operator too should have space either side.

That is correct, and I believe it is in our standard.

hgtonight

@Linc said:

@x00 said:
I'm in favour of this style of concatenation

Unfortunately, we've standardized on the latter (no spaces).

@x00 said:
any operator too should have space either side.

That is correct, and I believe it is in our standard.

Excepting the concatenation operator

I don't really care, just thought it was a funny juxtaposition.

x00

@Linc said:

@x00 said:
I'm in favour of this style of concatenation

Unfortunately, we've standardized on the latter (no spaces).

x00

One of the problem you have is old variable and properties that started with upper-case.

So we have a situation with two styles side by side.

Things like ->data() vs ->Data sometimes you do want to access it directly.

Linc

@x00 said:
One of the problem you have is old variable and properties that started with upper-case.

One day we'll do a big backwards compatibility break and go for 3.0. Until then, best to leave variable casing alone.