Realistically, quoted identifiers (table and column names mainly) are only essential if you're using reserved keywords inside of a query. But, Joomla seems to have a thing for quoting everything possible so people spend less time thinking about whether quoting is necessary. So yes, for consistency it probably should be quoted, but no it is not mandatory.

And if you really wanted to get obsessive about it, the right line would look something like this:

// Using sprintf because there's way too much concatenation otherwise
// Results in LEFT JOIN `#__categories` AS c ON `c`.`id` = `a`.`catid` for MySQL
$query->join('LEFT', sprintf('%s AS c ON %s = %s', $db->quoteName('#__categories'), $db->quoteName('c.id'), $db->quoteName('a.catid'));

less readable that way at my eyes, i would prefer

$query->join(
'LEFT',
 $db->quoteName('#__categories', 'c'), 
 $db->quoteName('c.id') .' = '. $db->quoteName('a.catid')
);

but just my personal taste

I always think that the code in joomla should serve as a good example to extension developers and site builders. Most know nothing about php code they just know about joomla code - and then like me not very much and need to learn by example.

It really does look very odd when you get mixed styles in the same query

less readable that way at my eyes, i would prefer [snip]

Can't get that one without a hard B/C break in the API (splitting the existing second param into two separate parameters, one for the table name and one for the join condition). You're right it's more readable, but realistically the ship has sailed already on having a query builder API that is also human eye friendly.

@brianteeman
good point indeed,
and mostly my fault triyng to convert SQL to prepared statement, in a fast way

@mbabker
not sure why you call an hard B/C break

this is a much more clean example maybe

Oh, nevermind. Apparently this has already changed (with only part of the hard B/C break).

The signature in 3.x is:

public function join($type, $conditions);

In 4.0, after joomla-framework/database#143, the signature is:

public function join($type, $table, $condition = null);

So the way you suggested works.

There is a B/C break in the changed signature if anyone has custom query builder classes, but it's not B/C breaking to users of the API since the base class is accounting for both the old usage and new usage (basically since the $condition parameter is nullable it avoids the worst breaking change that could be made, and that's what I was worried about happening).

Closing as my question was answered