Toad World® Forums

Formatter uses too many lines

All,

I’m currently on 12.11.0.77.

In the formatter options, list arrangements, parameters, I have set:

  • List arrangement: Stacked on overflow or more than 3
  • Parentheses:option 2
  • On overflow on 1, 2, 3 then use: option 5

With the current code this results in parameter sprawl over an excessive number of lines,
reducing readability and maintainability of the code :frowning:

For example I now get:
if lower(p_debug) = ‘debug’
then
utl_krg.msg_log.log_debug_msg(
p_schema =>
g_my_schema
, p_package =>
g_my_package
, p_routine =>
l_my_routine
, p_action =>
l_action
, p_msg_id =>
g_my_msg_prefix || ‘0035D’
, p_message =>
‘reread check: l_app=’
|| coalesce(l_app, ‘<*null>’)
|| ‘, g_getkrg_last_app=’
|| coalesce(g_getkrg_last_app, ‘<*null>’)
|| ‘, g_mqget_retry_time=’
|| coalesce(trim(to_char(g_mqget_retry_time)), ‘<*null>’)
|| ‘, localtimestamp=’
|| coalesce(trim(to_char(localtimestamp)), ‘<*null>’)
);
end if;

Where the formatter in 12.10.0.30 gives me:
if lower(p_debug) = ‘debug’
then
utl_krg.msg_log.log_debug_msg(
p_schema => g_my_schema
, p_package => g_my_package
, p_routine => l_my_routine
, p_action => l_action
, p_msg_id => g_my_msg_prefix || ‘0035D’
, p_message => ‘resend check: l_app=’
|| coalesce(l_app, ‘<*null>’)
|| ‘, g_putkrg_last_app=’
|| coalesce(g_putkrg_last_app, ‘<*null>’)
|| ‘, g_mqput_retry_time=’
|| coalesce(trim(to_char(g_mqput_retry_time)), ‘<*null>’)
|| ‘, localtimestamp=’
|| coalesce(trim(to_char(localtimestamp)), ‘<*null>’)
);
end if;

Which is more both compact and better readable.

I assume some customer(s) have asked questions that have prompted the change in formatter behavior,
so I’m not going to ask for a reversal of the change. But could we have a formatting parameter,
to force or not force all parameters onto a separate line if any parameter overflows?

While I’m at it, we’d also like a distinction between Oracle supplied functions, and user-defined ones.
Would it be possible to have separate formatting rules for these two categories of functions?

Kind regards,
Abe Kornelils

Please let me elaborate on the distinction we’d like to make between Oracle-supplied functions and user-defined ones.
What I meant was a distinction between SQL-defined functions (e.g. SUBSTR, INSTR, COALESCE, etc) and
all other functions and procedures, including not only our own ones, but also all Oracle-supplied packaged functions
and procedures.

For formatting SQL-defined functions, we’d like to have as many arguments on a line as will fit,
but for all others, parameters should be stacked.
Our current setting of “Stack when more than 3 parms are present” accommodates SUBSTR to have
all of its arguments on a single line, but also allows user functions with two or three parms to have them
all on one line.

If the distinction between SQL-functions and all others functions/procedures is a difficult one,
I think we also could do with separate rule-sets for named and unnamed parameters.
After all, on SQL-functions one does not normally specify the parameters by name,
while on other functions/procedures we do have the habit of explicitly naming parameters.

I hope this helps.

Kind regards,
Abe

Hello Abe,

I’ll add that to the other threads

http://www.toadworld.com/products/toad-for-oracle/toad_for_oracle_beta_program/f/86/t/32604 and

https://www.toadworld.com/products/toad-for-oracle/toad_for_oracle_beta_program/f/86/t/32152

which are in the works. (QP-2344)

Thanks,
Andre

Please refer to http://www.toadworld.com/products/toad-for-oracle/toad_for_oracle_beta_program/f/86/p/34361/67664#67664 for further discussion.

Fixed in component QP5 version 5.320.

Correction: Fixed in component QP5 version 5.319.