Formatter breaks on %

[Roel]

When using long procedure names, parameter names and types, the formatter generates a break between % end type (see below). Obviously this should never happen.

   procedure process_doc_aggregate(p_id                           in out document_aggregate_vw.id%type,
                                   p_doc_id                       in out document_aggregate_vw.doc_id%type,
                                   p_exclude_auto_distribution_yn in     document_aggregate_vw.exclude_auto_distribution_yn%
                                   type,
....

[Philipp Salvisberg]

I can reproduce it with the current Advanced Format (xml) and the Custom Format (arbori) settings in SQLDev 21.4.2.

I used this input:

create package pkg is
   procedure process_doc_aggregate(p_id                           in out document_aggregate_vw.id%type,
                                   p_doc_id                       in out document_aggregate_vw.doc_id%type,
                                   p_exclude_auto_distribution_yn in     document_aggregate_vw.exclude_auto_distribution_yn%type);
end;

I can reproduce this also with the SQLDev's default Arbori program. You can activate that by pressing the reset button in the custom format screen.

This Arbori program has a different formatting logic, so I made the last parameter longer to produce the same problem. This is the input:

create package pkg is
   procedure process_doc_aggregate(p_id                           in out document_aggregate_vw.id%type,
                                   p_doc_id                       in out document_aggregate_vw.doc_id%type,
                                   p_exclude_auto_distribution_yn1234567890123456789012345678901234 in     document_aggregate_vw.exclude_auto_distribution_yn%type);
end;

And the formatted result looks like this:

create package pkg is
   procedure process_doc_aggregate (
      p_id                                                             in out document_aggregate_vw.id%type,
      p_doc_id                                                         in out document_aggregate_vw.doc_id%type,
      p_exclude_auto_distribution_yn1234567890123456789012345678901234 in document_aggregate_vw.exclude_auto_distribution_yn%
      type
   );
end;

How does that help? Well, it shows that the Arbori program is not responsible for this behavior. Responsible is another component. I call it "Serializer" in this blog post. This component is also responsible to handle lines that exceed the specified max. char line width (120 in this case).

I see the following options to "solve" this particular problem:

a) increase the max. char line width setting
b) change the line splitting logic by adding a line break at a more suitable place and therefore ensure that the serialize will not add unwanted line breaks.
c) add manually a line break after the opening parenthesis, this will lead to a more compact formatted representation which does not exceed the max. char line width. This is an advantage of the lightweight formatter that supports various formatting styles.

In a perfect world I would like to implement another option

d) keep the line as is, do not add a line break between % and type

Unfortunately option d) must be implemented by the SQLDev team.

@APEXGru: is option a) or c) acceptable for you? If you vote for option b) can you please suggest where a line break would be acceptable? And if you are all in for option d) then we would need to open an Oracle SR to address this issue. I could do that. Thank you.

[Roel]

As a short term solution I will go for option a.) (increasing the max line width). I can confirm that works. Haven't thought of c., but that's also a fine option.

In general, if the SQL Dev formatter can make our code break (by adding a new line in a position were it shouldn't), then that is a bug IMHO. So it would be nice if it gets fixed despite of the (acceptable) workarounds we have.

Thanks.

[Philipp Salvisberg]

As a short term solution I will go for option a.) (increasing the max line width). I can confirm that works. Haven't thought of c., but that's also a fine option.

Cool

In general, if the SQL Dev formatter can make our code break (by adding a new line in a position were it shouldn't), then that is a bug IMHO. So it would be nice if it gets fixed despite of the (acceptable) workarounds we have.

I agree. But this is not the case here. It's valid to add whitespace between % and type. It's unusual, but it is valid code. Check it out! However, I agree that the formatter result does not look good.

[Roel]

Gee, I didn't know that. Apparently you can also have a space before and even before and after the dot that defines a column type (e.g.
table . column % type
is also valid)

[Philipp Salvisberg]

Gee, I didn't know that. Apparently you can also have a space before and even before and after the dot that defines a column type (e.g. table . column % type is also valid)

Right. You usually can place as many space, tab, line breaks between lexical tokens as you want. There are a few exceptions where a whitespace would break the code (e.g. for floating point numbers). There are much fewer cases where no whitespace between tokens is allowed. The minified() example gives an impression. It shows also differences between the capabilities of the SQLDev parser and the parsers in the Oracle Database.

[Philipp Salvisberg]

I think the current long lines handling is reasonable. There will be always cases where the split occurs in an unfortunate place. I do not want to create a precedent by handling '%type' differently. I think the user has enough options to handle such cases by explicitly adding line breaks at a better position.