These are for formatting lists and exist for different categories: control structures (like inside an if…), DML – for columns after SELECT, INTO, VALUES SET inside UPDATE, and finally a different option for parameter declaration (like in functions and procedures).ġ) On one line – means list items stay together on one line, no matter how long it becomesĢ) One per line – that is clear (and aligned according to vertical alignment rules)ģ) On one line if possible – takes into consideration the right margin (e,g.
OK, here is a feature description of managing formatting of new lines for item lists in different code structures. You are different… And, if the formatter in SQL Developer worked just a bit better, we could both have what we want.
I’d say “The goal of ‘extraneous non-printing characters’ in code is to improve readability of the code and only one set of ‘extraneous characters’ is indents, while others are things like aligning arguments, concatenation, datatypes, etc.Īnd to be clear, I’m not right aligning the code blocks, but instead right aligning the keywords used for each of the ‘code blocks’ in a SQL query.īut that’s me. You say “It seems to me that the entire point of indenting code, in any style and in any language, is to create visual blocks indicating dependency levels, and right-aligning – which nobody would dream of doing in any other language – entirely defeats that by creating an amorphous blob that is no help at all in taking in the structure.”
I totally understand you are not a fan, but do you really think that because you don’t like it, that no one else should be allowed to use it? Think of it like the outline view of the query “Here is the select clause, here is the join clause(s), here are the where clause(s), here is the order by clause, etc.
SQL Queries have very distinct clauses and it can be very nice to see each of those clauses lined up as a ‘gutter’, particularly when you use ANSI query syntax (I feel like signing a petition to ban the Oracle proprietary syntax where you can’t even do a full outer join and where clauses both join tables and filter rows). However, for many folks, SQL is a fundamentally different language than something like Java or Python or C, etc. Of course in a simple query like this, it is easy to see that I forgot to specify the columns to select, but why not report the error? The formatter does nothing and gives you know clue why not. It would have made it easier to understand that it didn’t recognize something rather than doing nothing and wondering why.
UPPER) to be considered as keywords for the purpose of capitalization.Īnd finally, the formatter should report error messages when it encounters code that prevents it from formatting. This is disappointing since Oracle obviously supports it and we use it frequently.Īdditionally, I would like standard Oracle function names (ex. It seems that the formatter does not like ANSI join syntax. I tried selecting parts of the query and applying the formatter and it worked until I reached the “JOIN ON” part. Unfortunately, the formatter wouldn’t make any changes to the query. …to look something like this after formatting. Join on item_table it on eo.unit_id = it.action_id AND it.type = ‘XX’ Unfortunately, it didn’t take long to find an issue.įor example, I would like this unformatted SQL… The formatter is specifically important because we use it to enforce coding standards. My team recently moved from Toad to SQL Developer because we only use Oracle and it seemed to be a robust tool that met our needs. I realize that this thread is about an older version of SQL Developer, but I couldn’t find a similar thread for v17.