Comments on: Clarity, Clarity, Clarity

By: Log Buffer #17: a Carnival of the Vanities for DBAs

Log Buffer #17: a Carnival of the Vanities for DBAs — Mon, 04 Feb 2013 16:15:07 +0000

[...] There’s a new kid on the blog — Jonathan Lewis, and his blog is the Oracle Scratchpad. Here’s a post of his on the virtues of clarity. And clarity and clarity. [...]

By: Jonathan Lewis

Jonathan Lewis — Fri, 10 Nov 2006 16:30:40 +0000

Gabe, there are some instructions about allowing code to survive the comments editor in the page “How to use”.
If you want to email me your source, I’ll reformat it and publish in your original note. In passing one of my “rules” on decode() is that if it’s not a one-liner, then the closing bracket should either be under the opening ‘d’, or under the first letter of the predicate that it completes.

By: Gabe

Gabe — Fri, 10 Nov 2006 16:11:52 +0000

Oh well. Here goes the clarity part.
I did hit the back button and checked that my entire comment was there, formatted and all … but it came out the way it did. So, that’s that then. Sorry about the mess.

By: Gabe

Gabe — Fri, 10 Nov 2006 16:04:08 +0000

Ok, so we agree then: it is an issue of taste … as in, appearances. We just reached different conclusions. In fact, to me, it isn’t as much commas at the beginning vs. commas at the end as the commas being equally indented or better said, being in a predictable, consistent place. It is for reasons of readability that I prefer it.

I don’t want to fill your blog with some ugly, nested SQL; I’m sure you’ve seen enough of that. But here is something small:

select rownum id,
decode(mod(rownum,10),0,null,
decode(rownum-1,0,null,rownum-1)) pid,
trunc(rownum/10) typ
from (select level from dual connect by level bad taste, but as long as I see the pattern, I’m good.

Cheers.

PS. A preview button will be nice here … will my sql come out LTRIMed or not?

By: Jonathan Lewis

Jonathan Lewis — Fri, 10 Nov 2006 07:25:08 +0000

Gabe, I have heard arguments for the “commas at beginning” – the worst one was that it’s easier for code-generators. There’s also the one about being able to delete lines more easily (which also applies to “and at the end”). Since I have to read code, I’ll always argue for styles that make it easier for readers, rather than writers.
On Unix I use vi, on Windows I use notepad, on VMS I use ed, on mainframes I use whatever they’ve got.

By: Gabe

Gabe — Fri, 10 Nov 2006 00:08:38 +0000

I also happen to dislike [snip] commas at the beginning of lines, but at least I can tell myself that that’s just a sign of poor taste.
Fair comment.
I’m guilty as charged then … and I’ll stay that way. Mind you, there is a reason for that poor taste. Just curious … what editor do you prefer when writing code?

By: Jonathan Lewis

Jonathan Lewis — Wed, 08 Nov 2006 07:56:02 +0000

Klabu, "order of the from clause" ... top to bottom, i.e. "lkd down to "ses". And to reduce the risk of any other ambiguity, this is reading down the left hand side of the predicates. Of course if I had to write SQL for the Rule Based Optimiser I would put the tables in the from clause in the reverse order because the RBO works from the bottom up (all other things being equal). This means that for RBO, my table ordering in the from and my predicate ordering in the where used (at the global level) to run in opposite directions to each other. (Within any one table, the same bottom-up to top-down rule switch still applies for filter predicates though, consider :


where
    colx = 99
and coyY = 'A'

RBO operates these from the bottom up, CBO operates them from the top down.)

By: klabu

klabu — Wed, 08 Nov 2006 03:55:58 +0000

>> Third I list the table names in the from clause in the order that I think the (cost-based) optimizer ought to visit them. The same ordering pattern appears in the where clause.
select from v$locked_object lkd, dba_objects obj, dba_rollback_segs rbs, v$transaction trn, v$session ses where obj.object_id = lkd.object_id and rbs.segment_id = lkd.xidusn and trn.xidusn = lkd.xidusn and trn.xidslot = lkd.xidslot and trn.xidsqn = lkd.xidsqn -- added for completeness and ses.taddr = trn.addr <<

So what is the order ???
“lkd” down to -> “ses”
or the reverse ?
Thanks

By: William Robertson

William Robertson — Mon, 06 Nov 2006 13:16:58 +0000

I don’t see how this depends on developers following conventions. I didn’t learn to write my join predicates the way I do by following a convention, I learned it all in the School of Hard Knocks.

The issue doesn’t go away with ANSI join syntax either. There is nothing to stop you writing

FROM a
JOIN b ON a.col = b.col

which to me, though not to everyone else apparently, is inconsistent with

WHERE b.deptno IS NULL

in that both specify something about a column of table B, but that column appears on arbitrarily different sides of the expression.

For ANSI outer joins we could even write

FROM b
RIGHT OUTER JOIN a ON a.col = b.col

which only makes the slightest sense if you read the query backwards.

By: David Aldridge

David Aldridge — Sun, 05 Nov 2006 15:47:29 +0000

>> … I edited your previous comment back into one piece

And not for the first time I think. Thanks … I’m going to try to have to remember not to write less-than signs.

You could well be right about the joins/predicate thing Jonathan, and maybe we encroach on differences between relational and SQL databases here. I’m pretty sure that in the pure relational sense there is a big difference, with selections, theta-joins, division. antijoins and whatnot, but the lines get blurred when one starts to consider the implementation in the RDBMS — maybe more particularly in a “SQL DBMS”. Maybe my differentiation between joins and predicates in SQL is just a relational pretension, but I’m not at all sure that I can give it up. When visualising queries I always find myself linking up tables with joins and then asa second step imposing the predicates on the result — if it is in one’s nature to imagine predicates on the leading table before joining up to other tables then I can see how “B=A, C=B” makes more sense. Maybe I should just start using the ANSI join syntax, but I’m not sure that I can take that step yet either :(

I like the idea of improving maintainability by documenting expected join order but it depends on an established convention that says “all developers will order joins in this manner” and once you have established a convention then the style of the convention matters less than that everyone stick to it. Compliance to that convention would be very tricky to check by eye, and if one was going to be super-rigourous in this respect then I’d be wanting some form of abbreviated explain plan appended as a comment. Or maybe that’s going too far … the more important part of the convention is that it is respected by all.

Let me just add on a note of self-interest that if someone is paying me cash-money to write code then I’ll adopt almost any convention they like, even to the extent of not using mixed-case. But I won’t do code in all upper-case — I’ll see myself and family destitute first :D