First of all, there have been religious wars over code formatting. Even the original post contains a possible declaration of such a war where the OP works.
I'm NOT trying to start one of those. I have methods that I use that make things really easy mostly for ME to read. It turns out that folks at work like the readability aspect and it's what most of us have followed at work for nearly a decade now.
To commence... (remember, this is what I do... no malice is intended here... unless you come to work for me someday 😀 ).
Bracketed names make certain searches very easy but I hate them, won't use them, and wrote the company spec to avoid them. To me, they create horrible screen clutter and increase the chances of having to scroll to the right, which I also hate.
I also strongly believe in using the 2 part naming convention and will usually use it even if only one object is present in a query just because I really like consistency and have also been burned when someone later modifies the code, like Thom posted. Solid 2 part naming also makes the code a lot more portable when someone moves to new databases and so I heavily enforce it even for things like the system databases in all but the rarest of cases. It's a whole lot easier to change synonyms than it is to change 3 and 4 part naming in any code. There's also that scrolling thing I previously mentioned.
Also, to support Thom on his claim that 3 and 4 part naming has been deprecated, take a look at the following article written by a really smart fellow who cites the actual Microsoft documentation on the subject.
As for the "key words on a separate line" format, I have a strong personal dislike for it because I hate scrolling left/right or up/down to read what should be short SELECTs, etc. At work, I have people break lines at character 120 (119 characters plus the end of line character fits in a 10 CPI monospaced font printed in landscape with 1/2 inch margins, which is also perfect for readability on most screens nowadays without scrolling.
There's a lot more. I have capitalization specs for different parts of queries and names. I prefer the ColAlias = expression format rather than the expression AS ColAlias format to make it much easier to find such things. While I don't enforce it for the company, I also self-enforce a strongly adhered to vertical alignment, a "river" format between keywords and other code, and right align most keywords on to the "shore of the river". Rumor has it that SQL Prompt also has such a format but I don't use such tools because they're not available on every machine that I have to touch.
I also "saw the light" (more burning involved) many years ago and converted to leading commas. It matches with the idea of me putting AND/OR etc in a leading rather than trailing position.
I also have a profound hatred for columns that have the 2 letter name of "ID" or "Id" or "id" and we follow a standard at work that covers what such columns must be named. With rare exceptions, they must be TableNameID. Yep... seems like overkill in properly aliased queries but it has saved lives in more ways than 1.
Almost everyone I tell this to thinks I'm slightly insane and the certain I suffer from massive OCD but, oh my, when they read the code I write the first time, they normally end up telling me that it's the easiest code to read that they've ever seen. The really funny part is, I don't actually write the code that way for other people... I write it that way so I can read my own stuff in the future. That's also why I comment the code the way I do... every SELECT (even in CTEs and Subqueries) has a purpose and I try to add a comment to each one to identify that purpose so that I don't have to read the code to find the code I'm looking for during modifications or cut'n'paste.
And to go a little on the Holy-War of proper naming conventions, I won't sign off on peer reviews, even if everything else is absolutely perfect, if column names are things like "DATE", "ID", "IsNotSomething", has characters that require brackets (except for certain reporting procs), is all lower or upper case, and I usually discourage underscores (there are certain good reasons to use the but not as a general replacement for spaces).
I also have a spec on what needs to go into the flower box, how to separate major sections of code, etc, and we have a template to make most of it easy.