It may be because I'm dyslexic, but over the years I have been a keen exponent of Defensive Programming. Of course different programmers will have different views on what works well etc., but any organisation which tolerates unformatted code would worry me as to the quality of the resulting APP. I'm not sure that every developer adopting their own style, provided by a formatting tool, and not having the ability to override that when the need arises is a good idea - although, for sure, it is better than no-style-at-all.
For example, we do some specific things because we think that they help with spotting bugs:
For JOINS we put all the columns for the target table on the left. Typically we are trying to satisfy the PKey of the target table, and thus seeing the columns, vertically aligned, on the left help ensure that all the necessary columns are included. More commonly I see the Target Columns on the right (or switching sides between one JOIN and the next, or even within a single JOIN [sigh!])
SELECT Col1, Col2
FROM Table1 AS A
JOIN Table2 AS B
ON B.PKey1 = A.SomeColumn
AND B.PKey2 = A.OtherColumn
AND B.PKey3 = 'FixedConstant'
We use the style
SELECT [AliasName] = ColumnName
because if the [AliasName] is on the right it may well be off the screen, or not easily spotted. We arrange them, neatly indented, so that they align vertically for easy reference and checking. Similarly we put any continuation operator at the start of the line, not the end, so that there is no accidental assumption that something [stretching off the right of the screen] is comma-terminated, and thus a new result column.
SELECT [MyAlias] = some + long + expression
+ continued + onto + next + line
, [NextAlias] = FooBar
I very much doubt that a Pretty Printer could do the former, maybe it could do the later, but we permit some leeway as to what is concatenated on a single line, and what is continued onto a fresh line. Often times the actual "trickiness" of the parts of the concatenation, or expression, influence the layout. For example, I don't necessarily want a CASE statement separated onto multiple rows:
CASE WHEN FooBar IS NULL THEN '' ELSE Some + moderately + complex + expression END
in this example the minimal blank-string is deliberately first (i.e. I would use IS NOT NULL if that was necessary in order to have the minimal expression first), and the major expression second as it immediately indicates that NULL is "ignored" and only non-null values have a detailed expression. If it were the other way around the blank-string might be off the right end of the screen and the developers would not know, without scrolling, whether there were two complex expressions, or whether one of them was trivial - and that will lead, on occasions, to the developer assuming the wrong thing which leads to bugs. The fact that the moderately complex expression may continue off the edge of the screen doesn't matter, enough of it is showing to indicate that there is an expression, which can be scrolled-to-read if necessary. Again, I doubt a formatting tool would turn the expression around to provide that sort of Defensive Programming visual feedback.
Our code styling is within a set of guidelines but there is plenty of personal choice as to where line breaks occur and the like. But I do expect that there are spaces around "=" for example and without doubt a formatting tool could do that part
[two] = foo, [twoA] = bar
On the first line pressing Control-Arrow skips straight to the end of the line. On the second it stops at each word-break. No doubt some people use a mouse for that type of editing, but we think we are more productive using keyboard controls for most maintenance-editing. And so my list goes on
Well ... not in SSMS which stops at every possible break character, which makes it useless as a productive editor for skilled keyboard users.
Cost of bug finding & fixing is significant, increasingly so the later in the process that bugs are identified. Over the years I reckon our strike-rate has been exceptionally good; I have plenty of experience as a consultant helping sort out significant problems in APPs and mostly I reckon that the problems could have been avoided if the coding style was not "casual coding". Of course most managers are not interested, because it increases DEV time by, say, 10%. By comparison reducing debugging time by 10% is a huge saving, but difficult to quantify that the saving has been made.
I have no doubt that some folk here will disagree with my formatting style choices, but that is not my point. My point is that developing a set of style guidelines, that works for you, and improves code quality and achieved Defensive Programming is a worthy goal, and I very much doubt that can be provided by a formatting tool. If one exists then Sign Me Up