The Ruby Style Guide

Hard to swallow without any reasons written behind each decisions.

Oh fun another style discussion! :-)

My own taste is for a "book style": write the code like you see in good books. I agree with most of this guide, although I'm pretty loose and case-by-case in practice. I've gradually added rubocop to lots of my projects, but then I wind up disabling tons of the rules.

I'm sad all the Ruby guides I've seen ban "and" and "or". I don't find them to be such an issue, and they are nicer to type & read. For one thing you can say `foo or raise "msg"` but need parens to say `foo || raise("msg")`. On team projects I sigh and go along with it, but it is a shame.

Speaking of "book style": I have a bunch of Python books with atrocious style, e.g. no spaces between operators or even between function arguments. How can anyone read that? I even see this from high-quality publishers like O'Reilly. What is going on with the Python world? Are their thumbs tired from all that indentation, so they leave out spaces everywhere else? ;-)

I really want to write a SQL style guide. There seems to be almost no consensus. My own formatting is idiosyncratic and not super principled, but I feel it is the most readable and expresses structure the best. It looks like this:

    SELECT  a, b
    FROM    t1
    LEFT OUTER JOIN t2
    ON      t2.t1_id = t1.id
    WHERE   t2.c = 'foo';

(EDIT: Sorry, t2.c = 'foo' is a pretty dumb thing to do in an outer join. :-)

Other people like to do one or more of these things:

    SELECT a
         , b
      FROM t1
           LEFT OUTER JOIN t2 ON t2.t1_id = t1.id
     WHERE t2.c = 'foo';

In other words:

- lead with the comma in SELECT.

- ragged left edge but line up all the single spaces in a column.

- indent the joins.

Anyway sorry for the rambling. :-) There is some observation that committees spend 90% of their time on trivial details and hardly discuss any of the important stuff, and style is no exception. But who doesn't like giving their opinion? :-)

Funny, I've been wanting to do/working on a SQL style guide myself, with a big emphasis on using leading commas because of the readability and easy-adjustability. I do something like this:

            SELECT  
                a, b
            FROM
                t1
            LEFT OUTER JOIN t2
                ON t2.t1_id = t1.id
            WHERE   
                t2.c = 'foo'
            ;

I don't like it. :-) Splitting each clause into two lines makes my eyes stumble. I can't read it as effortlessly as I read normal text. At least you are left-aligning the keywords though. :-)

I have two spaces after my SELECT because when you press tab that's where you wind up next. Keeping things tab-aligned lets you easily type it out without a lot of fuss. I think that gets you much of the benefit of your broken-line clauses without impairing reading flow.

Also on a monitor vertical space is scarce, so I'd like to keep that reasonably compressed.

I get how leading commas makes it easy to re-order projections but I've never heard anyone say it makes them easier to read. :-) (I have no problem putting them on multiple lines if you have a lot or some are long.) And I'd rather optimize for readability over not needing to add/remove a comma.

I can see why you'd indent `ON` although I prefer to keep its conditions at the same level as WHERE.

I also do the semicolon at the bottom thing a lot.

Anyway it's fun to trade tastes. :-) SQL is surprisingly hard to rule on when it gets complicated. I doubt I am consistent once I start adding subqueries, CASE, etc.

The only thing I really don't like here is non indenting when inside case. I know that technically it's not a block, but in practice I find it much less readable