|The current formatter only works well (that's an overstatement) for either SQL or PL/SQL. When adjusted to work well with SQL then PL/SQL looks terrible, and vice versa. SQL and PL/SQL are two separate languages and should have separate formatting rules.||10||05-DEC-14|
|Our generated source code is created line by line in an array of DBMS_SQL.varchar2s so it can be compiled directly. It would be useful to allow the formatter to work on the array within the database before compilation or dumping the contents of the array to an external file.
Site specific rules for the formatter API should be stored in the database so the formatter works consistently regardless of the client connected to it e.g. Sqlplus, sql developer or dare I say it toad. It would also be useful to allow import/export of these rules so it can be adopted across all databases in the estate.||10||29-JUN-14|
|Could this API be implemented (or at least callable from) the Oracle database e.g. A package perhaps named DBMS_FORMATTER. This would allow code generated by other PLSQL packages to benefit from defined coding standards.||10||29-JUN-14|
|Lines should be indented within if/end if loop/end loop. Also nested loops and if/then should be indented as well.||10||15-MAY-12|
|Formatter has a lot of scope for improvement.
1) Handling nested conditions properly. I mean properly indenting the inner and/or clauses.
2) Holding multiple keywords on a gingle line.
The below code could be on a single line.
TABLE OF XXX_POSITIONS%ROWTYPE;
3) Change case should have facility to combine "Key Words Uppercase" and eveything else lower case.
(Now we have options for entire sql upper/lower case. That doesnt work well if we want the key words upper case and the rest lower case.)
|Formatted code is practically unreadable. It strips all whitespace, and the indentation makes it difficult to read. An API would allow implementation of formatting standards and consistency for a team.||10||10-AUG-11|
|Too many point where formatter breaks a ||10||15-DEC-09|