Teams and developers will frequently argue about code being ‘ugly’ or ‘hard to read.’ While we can say these are subjective points or opinions – at a certain point, ugly code is ugly code.
I found this tweet to be quite funny the other day. Do you imagine your code SHOUTING every time you ask for your data?
It's all about efficiency pic.twitter.com/3b4j5qOIAv
— Molly Struve(@molly_struve) January 22, 2021
(@molly_struve) Anyway, even though ‘the beauty of code’ might be subjective, it doesn’t mean we can’t find a set of guidelines that most of us can agree with. And with this good base to start from, you can always change things up here and there to meet your needs.
Trivadis has put together a set of these guidelines. And they’ve been through many iterations and improvements – the current version is 3.6!
Their current rules, as of today, are –
Trying these rules in SQL Developer is EASY – thanks to Philipp!
Philipp Salvisberg put in the time to implement these rules using Oracle SQL Developer, and has put them on Github for anyone to use.
People are frequently telling me, ‘hey I hate the way SQL Developer formats code,’ but I don’t always have a great answer other than to say, hey, you can change that!
With this set of rules, I can now share this confidently knowing that at least a good portion of the Oracle developer community agrees 
Note: You must be on AT LEAST version 20.4 of SQL Developer or SQLcl for these to work.
The Before
Stock SQL Developer, default formatting rules.
I’m also using the ‘Hack’ font, which is included with version 20.4 now. You’ll want to use a FIXED WIDTH font for reliable display of code!
So I have UPPER keywords, lower identifiers, indent is set to 4, we have trailing commas…that much is clear from this screenshot.
Now, let’s see what happens when we apply the Trivadis coding standard rules for SQL Developer.
Trivadis PL/SQL & SQL Coding Guidelines v3.6
Downloading the zip, and grabbing the XML, and then pointing that to the ‘Import’ button on your advanced format rules page in SQL Developer –
There’s one more file (arbori), and this is where I imagine Philipp put in a majority of the work. Our formatting engine allows for customizations ABOVE what the preferences show in the GUI. Philipp did just that, and we can just take advantage of it.
Ok, let’s take a FULL look at the code sample, now with all 77 lines of it in full view.
I think this will work for me
But wait…did you notice? One of the rules has been…broken
Commas. People have opinions. It’s up to you, choose wisely!
“Enforcing” these rules
What I’ve found to work best –
- set your rules
- tell developers they have to follow said rules
- be prepared for developers to ignore said rules
- developers check code into source control (you DO control your source code, yes?)
- system admins batch format all of the code in the repo
- as soon as someone pulls their file, they’ll format it back the way they like it
The post Trying out Trivadis’ Code Formatting Rules, Thanks Philipp! first appeared on ThatJeffSmith.