multi-line Strings

[BGB]

Good, it's not just me that dislikes Python.

I am not so fond of Python either...

but, to each his own...


WRT scripting, many people like Python, many others prefer Lua, and I
myself, prefer my own obscure ECMAScript-based language, and, elsewhere,
I have seen plenty of people hate on ECMAScript and friends (JavaScript
and ActionScript) as well...

or such...

 

[William Bonawentura]

IMHO final code does not need to have any strings literals. Strings should
be allways created via out-of-code resources.

 

[Arved Sandstrom]

Yes, couldn't agree more. The only languages I've used that approach the
ugliness of Perl are Python (its object construction and handling are
every bit as nasty as Perls) and RPG II (designing an HLL to look exactly
like a fixed field assembler is just plain perverse).

I'll use awk+bash in preference to Perl any day. However, Perl almost
certainly inherited its use of /regex/ delimiters from awk, which is a
fairly elegant and minimal scripting system and I do like those
delimiters.

Don't forget that Perl, in its earliest form, was very obviously built by
mashing together a lot of Bourn Shell syntax with bits nicked from awk
and sed and completed by shovelling in the most useful bits of several
small UNIX utilities. Larry Wall has always acknowledged that as being
its origin. Its got a bit more structured and usable since then, but IMO
its still damned ugly.

I'm not all that religious about any language, but let's spread the lack
of love around - Java can be awesomely ugly when it hits a problem it's
not suited for. And it often doesn't compete nearly as well as, say,
Perl or Python, if it's in a problem realm where it results in 3x or
more code to solve a given problem.

I just now close-of-business yesterday finished a chunk of code that
despite some 15 years of working with Java isn't anything but ugly...and
I stipulate that it's not an uncommon ugly as far as Java and certain
types of problems go. Very complex SQL so a native JPA query that needs
to be assembled, trees using the Swing implementations, enumerations,
iterators, *lots* of list operations, *lots* of conditional intermediate
getter and setter operations to build the list of final result objects
to pass back to XStream for the REST call response...it's not pretty.

In a problem like this Java becomes kludgy because of death by a
thousand cuts. You do everything best practise (or decent practise) and
you still end up with hard-to-read clumsy code: no type inference so too
much verbiage, no C#-style properties so dozens of getter/setter usages
start looking pretty opaque...a Perl or Python equivalent _would_ look
considerably better. Ironically even the use of longer, descriptive
variable and method names can be self-defeating in this scenario - it's
just more bloat.

And it's telling that you have libraries like StringUtils or Google
Guava that supply a list "join" method if you don't care to write your
own loop to handle it. Another one of those thousand cuts that adds to
the bloat.

I'll probably end up refactoring some of the code - but in another
language like Perl or Python or Scala or Ruby or C# I'd not have to
refactor in the first place.

AHS

 

[Arne Vajhøj]

IMHO final code does not need to have any strings literals. Strings
should be allways created via out-of-code resources.

In general yes.

There are probably some exceptions. I would not want Java keywords to
come from an external resource for a Java compiler.



Arne

 

[Joshua Cranmer]

I've always liked the Awk and Perl default convention of delimiting
regexes with slashes: /regex/ - if their compilers can deal with this
cleanly, the Java compiler could surely do the same.

Which works really well until you want to match the / character in
pathnames. Or you want to lex but not parse the language--note that
/foo/ is lexed as a regex if the preceding token is an operator and
lexed as a sequence of tokens (DIV, IDENT, DIV) if the preceding token
is an operator.

 

[markspace]

I stipulate that it's not an uncommon ugly as far as Java and certain
types of problems go. Very complex SQL so a native JPA query that needs
to be assembled, ...
getter and setter operations to build the list of final result objects
to pass back to XStream for the REST call response...it's not pretty.

I'd love to see a smaller, non-proprietary version of that code, just to
see if we can't make some suggestions how to improve things.

 

[BGB]

In general yes.

There are probably some exceptions. I would not want Java keywords to
come from an external resource for a Java compiler.

IMO, about the only things (strings-wise) which really make sense being
moved into external resources are:
default configuration options (debatable, if the config file will
override them anyways);
(potentially) messages intended for human readers or similar (say, to
allow language-specific translations or similar).


if the bulk of the string literals are things internal to the program
(rather than intended for an end user), then it makes little sense to
move them to external resources (IME, most string literals tend to be
program internal anyways, with human-readable messages few and far
between, and most of these in-turn being internal debugging messages).

with user-readable strings, the program could still be developed under a
policy like "if you need the messages in a language you can read, either
learn English (or Japanese or Chinese or similar) or get a dictionary",
so making them external may not make much sense in this case.


even with language-specific strings, unless using magic numbers, a
string may still be needed to refer to them.

 

[Eric Sosman]

IMHO final code does not need to have any strings literals. Strings
should be allways created via out-of-code resources.

String message1 =
readFromURL(Thing.class.getResource("message1"));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromURL(Thing.class.getResource(
"name_of_message1"))));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
"name_of_name_of_message1"))))));
// Code reviewer vetoes the in-line literal, and
// gets badly mauled by fed-up programmer.

 

[BGB]

I'm not all that religious about any language, but let's spread the lack
of love around - Java can be awesomely ugly when it hits a problem it's
not suited for. And it often doesn't compete nearly as well as, say,
Perl or Python, if it's in a problem realm where it results in 3x or
more code to solve a given problem.

same here, mostly not very language religious (and use several
languages, although admittedly the bulk of it is written in C and some
C++, 1).

1: C (and to a lesser extent C++) is fairly good for infrastructural
code, but sadly, using it itself seemingly creates a need for large
amounts of infrastructural code (and, as well, the "libraries" space is
often very fragmentary, and 3rd party libraries are very much often "use
at your own risk"). (a multi platform project also ends up with a lot of
"portability boilerplate" as well).


in contrast, Java is much better for tasks which involve "using things
provided by the class library" (or, at least, this has been my
experience). a big comprehensive library at some cost that writing code
for things not provided by the library is a bit more painful (partly due
to the languages' relatively minimalist semantics, vs, say, C or C++).

C# is a little more of a compromise, but has a big drawback of being
tied mostly to Windows and .NET (portability in C# is not entirely
non-existent, after all there is Mono, .GNU, ..., but is not exactly a
strong area for the language either...).


me remembering a recent example, looking where a person tried writing an
H.264 codec in Java, and apparently gave up partly through (though, as
an external observer, one can't be sure if this was more due to the
general pain of writing an H.264 codec, or the specifics of writing an
implementation in Java).

(admittedly, it is bad enough writing these sorts of things in C#, and
Java would pose some additional issues, as in many ways they run at-odds
with the language-design choices).


sadly, a lot is a case where choices made which may offer benefits in
one area come at costs in another area.


not sure if anyone will try to argue all this.

I just now close-of-business yesterday finished a chunk of code that
despite some 15 years of working with Java isn't anything but ugly...and
I stipulate that it's not an uncommon ugly as far as Java and certain
types of problems go. Very complex SQL so a native JPA query that needs
to be assembled, trees using the Swing implementations, enumerations,
iterators, *lots* of list operations, *lots* of conditional intermediate
getter and setter operations to build the list of final result objects
to pass back to XStream for the REST call response...it's not pretty.

In a problem like this Java becomes kludgy because of death by a
thousand cuts. You do everything best practise (or decent practise) and
you still end up with hard-to-read clumsy code: no type inference so too
much verbiage, no C#-style properties so dozens of getter/setter usages
start looking pretty opaque...a Perl or Python equivalent _would_ look
considerably better. Ironically even the use of longer, descriptive
variable and method names can be self-defeating in this scenario - it's
just more bloat.

pretty much...


descriptive variable-names can be a double-edged sword.

in some cases, they can make the code "more obvious", especially if the
variable has "some well-defined meaning readily expressible in words".

in many cases, there are no words to express just what exactly this
variable is being used for, or it is being used as part of a big/hairy
set of mathematical expressions, making the use of a longer variable
name considerably more painful (like a single calculation spread over 4
or 5 lines).

there are still cases where multiple lines are needed for some
calculations, even with single-letter variables.


usually, using longer method names is not as big of an issue, since IME
method calls tend to be used at a lower density than that of variables,
and also because the choice of method names often has a lot more effect
on code outside the class, whereas variable names are typically much
more local to a given class or method.


my policy in general though is more often to not rigidly adhere to any
particular conventions, but rather to adjust conventions more "as they
make sense for a particular piece of code" (though sometimes this can
get at-odds with an IDE which does auto-formatting...).

And it's telling that you have libraries like StringUtils or Google
Guava that supply a list "join" method if you don't care to write your
own loop to handle it. Another one of those thousand cuts that adds to
the bloat.

I'll probably end up refactoring some of the code - but in another
language like Perl or Python or Scala or Ruby or C# I'd not have to
refactor in the first place.

yep, could be.

 

[BGB]

String message1 =
readFromURL(Thing.class.getResource("message1"));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromURL(Thing.class.getResource(
"name_of_message1"))));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
"name_of_name_of_message1"))))));
// Code reviewer vetoes the in-line literal, and
// gets badly mauled by fed-up programmer.

String message1 =
readFromURL(Thing.class.getResource(
new String(new char[]
{ 'm', 'e', 's', 's', 'a', 'g', 'e', '1' } )));

but, yeah, banning string literals would be stupid...

 

[BGB]

[...]
but, yeah, banning string literals would be stupid...

That said, I think there's a good argument for insisting that most if not
all string literals be declared as constants (e.g. final fields in the
class or a separate static class), rather than being found inline with the
code.

You don't get out of having string literals, but at least they are in a
centralized place or places, and when the same value is required in
multiple places, changes to the value or refactorings of the code are
simplified in this way.

yep, this makes sense...

it is along similar lines though to the avoidance of "magic values"
being declared inline in code.

sometimes, a value makes more sense as a constant variable, and people
will declare it as such. other times, it does not, and will typically be
left inline.


IMO, all this isn't really an area tools should get involved with
enforcing though, since tools can't really know whether or not something
"makes sense", they will just uniformly enforce various rules whether or
not they make sense in a given situation.

sort of like life in general I guess...

 

[Sebastian]

It could be added....

But I would not consider it a high priority.

It is most useful for demo code.

For real code then large chunks of texts would usually
be stored externally (file, DB etc.) not embedded into
the code.

I think nobody has mentioned this funny little hack, which just
might be suitable for demo code and unit tests. It requires that the
source code using the multi-line string be accessible in the file
system at run time.

http://blog.efftinge.de/2008/10/multi-line-string-literals-in-java.html

I do believe the blog was posted in a humorous spirit.

-- Sebastian

 

[Jim Janney]

Should something be added to the Java language to make multi-line Strings more clear?

Maybe like what PHP has?

Right now, I have a mess like this:

You could always write something like

private final String mLomoishShader = multiline(
"precision mediump float;",
"uniform sampler2D tex_sampler_0;",
"uniform vec2 seed;",
....
" float dist = length(coord * scale);",
" float lumen = 0.85 / (1.0 + exp((dist * inv_max_dist - 0.73) * 20.0)) + 0.15;",
" gl_FragColor = vec4(bw_color * lumen, color.a);",
"}");


private static String multiline(String... lines) {
// left as an exercise for the reader
}

 

[Lew]

You could always write something like

private final String mLomoishShader = multiline(
"precision mediump float;",
"uniform sampler2D tex_sampler_0;",
"uniform vec2 seed;",
...
" float dist = length(coord * scale);",
" float lumen = 0.85 / (1.0 + exp((dist * inv_max_dist - 0.73) * 20.0)) + 0.15;",
" gl_FragColor = vec4(bw_color * lumen, color.a);",
"}");

private static String multiline(String... lines) {
// left as an exercise for the reader
}

Interesting idea, modeling a multi-element thing as a multi-element thing.

Hardly seems less advantageous than the proposed new syntax, and evitates the
Gorgon Language Change.

 

[markspace]

Interesting idea, modeling a multi-element thing as a multi-element thing.

Hardly seems less advantageous than the proposed new syntax, and evitates the
Gorgon Language Change.

The disadvantage to this method is his method, multiline(), has to
assemble the string at runtime, and also has to make some assumptions
about what style of newline to use.

Whereas static strings are just that: static, don't need assembly, and
the programmer specifies the newline character(s) directly.

 

[Arne Vajhøj]

I think nobody has mentioned this funny little hack, which just
might be suitable for demo code and unit tests. It requires that the
source code using the multi-line string be accessible in the file
system at run time.

http://blog.efftinge.de/2008/10/multi-line-string-literals-in-java.html

I do believe the blog was posted in a humorous spirit.

Well - it is funny and not very practical (think more
than one such string), so that seems very plausible.

Arne

 

[William Bonawentura]

String message1 = readFromURL(Thing.class.getResource("message1"));

Eric Sosman

Uggly. Untestable in build-time. Consider something like this:


@Inject
@Resource( "message1" )
private String message1;

 

[Lew]

Consider something like this:

@Inject
@Resource( "message1" )
private String message1;

Works a treat.

I recently had occasion to work up an annotation to cover some ugly,
testable but twisted reflective code.

Writing the annotation gave multiple advantage, many quite unforeseen.

- Boilerplate code vanishes from annotated call sites.
- Leaving behind short, easy-to-comprehend routines.
- DRY - all the magic moves into one class that handles the annoation.
- Since you're in ReflectionLand anyway, you get a lot of data for logging calls.
- Orthogonal treatment - other code and tooling can use the same annotations
in novel ways with zero influence on existing consumers.
- Annotations contribute to self-documentation at least as much as boilerplate
detracts, squaring the benefit to code literacy.
- Adding modules to the system using the same annotation is super easy.
- When another programmer returned from leave, they were able to jump right
in and add another module the same day, leveraging the annotation.

JPA annotations are a good example of some of those bullet points.

Even though in this particular case I was one of the main proponents of the
annotation approach, I am still stunned at how well it worked.

Oh, that brings up another benefit. Intra-team communication around implementations
using the annotation is accelerated. It's largely because with an annotation there's
nothing to talk about once you've developed it. I had to explain the boilerplate a lot,
which is part of what led to writing the annotation. No one yet has needed an explanation
of the annotation beyond how its 'value' attribute connects it to the rest of our
lattice, and that but once.

 

[Arved Sandstrom]

Uggly. Untestable in build-time. Consider something like this:


@Inject
@Resource( "message1" )
private String message1;

You missed Eric's point. You stipulated a rule - "final code does not
need to have any strings literals. Strings should be always created via
out-of-code resources". You just now broke your own rule with your
annotation example; the absurdity of your rule is what Eric was trying
to illustrate.

AHS

 

[William Bonawentura]

Strings should be always created via out-of-code resources".
You just now broke your own rule with your annotation example;

String literal inside annotation is not equal to literal inside code. It is like static constans - you can read it on code-buld
phase ex. by Annotation Processor.

the absurdity of your rule is what Eric was trying to illustrate.

There is good a "rule of life" . Never create literals in the code.