Improve blank line break handling in generated code

[nemecec]

Description

Limiting number of empty line breaks in Mustache output is a known issue and it seems there will be no "fix" for that coming from Mustache team.

Example (generated with latest master):

  /**
   * Unique identifier for this bid. Read-only.
   * @return id
  **/
  @ApiModelProperty(value = "Unique identifier for this bid. Read-only.")



  public Long getId() {
    return id;
  }

This is clearly broken.

While Mustache is unable to fix this issue themselves (due to the way it generates output), Swagger Codegen can roll its own fix, following the example as outlined in that same issue.

Short summary: use some special non-whitespace character to represent line break in all templates. Post-process output from Mustache, removing all line breaks (\n) and replacing the special character with line breaks instead.

Swagger-codegen version

All versions so far.

[wing328]

One way we've been using is to use the following:

{{#someTag}}
....
{{/someTag}}

This will not output anything is someTag is false or empty.

Would that help?

[nemecec]

Yeah, I looked at the source code and saw such usage. While it does reduce whitespace it is still quite difficult to figure out what will be the exact output. And this is also rather error prone.

My proposal would make it much more explicit and less error prone. But I admit, it is quite a radical change which will most likely break any custom templates out there that users have written themselves.

It will also require someone to go over the existing templates and make sure that line breaks are added in all the right places.

[wing328]

Btw for 3.0.0-beta, the plan is to use handlebars instead of mustache: https://github.com/swagger-api/swagger-codegen/releases/tag/v3.0.0-rc0

Let us know if you've any feedback on that.

[nemecec]

Assuming that https://stackoverflow.com/questions/15953293/handlebars-whitespace-control lists the basic options for whitespace control in Handlebars, I would say that while it gives you more control, it is still rather complicated syntax-wise.

So I think my proposal is still better - easy to understand and reason about, resulting in better template readability and more pull requests from users.