[PROPOSAL] Change of convention for multiline string literals

Hello,

I would like to propose a change to the way multiline string literals are
expressed, such as where the default text of a configuration file is being
compiled in as a single string literal. Presently, such situations are
expressed in the form:

    contents =
      "#!/bin/sh"
      APR_EOL_STR
      APR_EOL_STR
      "# PRE-REVPROP-CHANGE HOOK"
      APR_EOL_STR
      "#"
      APR_EOL_STR
      "# The pre-revprop-change hook is invoked before a revision property"
      APR_EOL_STR
      .
      .

I find this format very difficult to read. I would like to propose the
following:

1. That the newline constant (well, macro) be placed on the same line as
the line of text it is terminating.

2. That for a given block, the newline be in the same column, and that
column be chosen such that the macro is separated by 2 spaces from the end
of the longest string in the block.

3. In recognition of the fact that some people would prefer to keep lines
shorter, that the macro be renamed to SVN_NL (simply by #define'ing SVN_NL
to APR_EOL_STR). For consistency, this macro should then be used throughout.

4. That blank lines in the string contain a left-aligned "" to emphasize
that the line is in fact present.

5. In the rare case where the longest line is just too long to be used to
select the column, that the newline appear in the correct column of the
following line, *without* a left-aligned "" as it is not a different line.

I have attached a patch which effects these changes. If it is accepted, I
would prefer to have it committed before I start making changes to the
authz unit test; the authz unit test is one of the places where test files
are expressed with the newlines on their own lines, and I find it very hard
to read and difficult to work with.

The attached patch contains no semantic changes; it simply defines SVN_NL
and replaces APR_EOL_STR with it, and reformats all giant multi-line string
literals into a much more readable format (in my opinion, at least).

Comments?

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org