That's why in most programming languages the coding style says you should put the operators at start of line instead of end of line, e.g.
GOOD:
if ((...some_condition_that_may_make_sense...)
&& (...some_other_condition...)
&& (...and_yet_some_condition_that_makes_sense...))
x = ((some expresssion)
+ (some other expression of different length)
- (some final expression))
BAD: if ((...some_condition_that_may_make_sense...) &&
(...some_other_condition...) &&
(...and_yet_some_condition_that_makes_sense...))
x = ((some expresssion) +
(some other expression of different length) -
(some final expression))
Examples:- Python PEP-0008: "Should a line break before or after a binary operator?" https://www.python.org/dev/peps/pep-0008/#should-a-line-brea...
- Topvoted SO answer for "If you break long code lines, how do you indent the stuff on the next line?" http://stackoverflow.com/a/699347
Never realized I could do tuple compare and will probably adopt that.
>> prefer tuple comparisons of multi-comparisons,
>> i.e. "(a,b)=(c,d)" instead of "a=c and b=d"
> never realized I could do tuple compare and
> will probably adopt that.
Indeed. Mind blown. select t1.col1,
t2.col2,
t3.col3,
t4.col4
from table1 t1
join table2 t2 on t2.colx = t1.colx
join table3 t3 on t3.coly = t1.coly
join table4 t4 on t4.colz = t3.colz
join tablen tn on tn.coln = t1.coln
where tn.colnx in (...)
-- Table 3 and Table 2 have some values while Table n value is not something OR Table n has value that is exactly something
and (
(t3.col = x and t2.col = y and tn.col != z)
or
tn.col = z
)
...
So in above you can see by the indent on which table some other table is joined to. Tables t2, t3 and tn are related to t1, but t4 is related to t3, not directly t1.There is not always "the" table.
How does your coding style work if you join into multiple tables? (because in reality you join the new table with the joined result of the previous tables, and hence can reference any combination of any previous table columns, unless you group your joins with parentheses)
select
...
from
table1 t1
join
table2 t2 on t2.colx = t1.colx
join
table3 t3 on (t3.coly, t3.colz) = (t1.coly, t2.colz)They are at the top of the hierarchy of information I want when I'm reading a query.
The information I want to be able to identify the quickest are.
1. Tables/view names
2. How they are joined
3. Columns
4. Filters
5. Grouping/Ordering/Anything Else
There are the exceptions of very widely used projects where contributors will only look at the code a couple times when making a change to be pushed upstream or where there are significantly junior developers that need a narrow scope of the language to help them with the learning curve and getting up to speed with the code base.
In my experience(which is very anecdotal I admit), the requirement for consistency is more about a particular personality trait that many developers have - the need for order and control - as opposed to a requirement for quality production code.
1. "join"s are at the same level as "from", and the contents of from/join are indented
2. prefer tuple comparisons of multi-comparisons, i.e. "(a,b)=(c,d)" instead of "a=c and b=d"
3. operators auch as "and" are at the beginning of a line, as in style guide of almost all other programming languages, too
4. the contents of "order by" and "group by" are also indented, the same way as the "select" columns
Example: