3d attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling)

[Dalibor Topic]

Salut Etienne,

Etienne Gagnon wrote:
> Hi Dalibor,
>
> I would drop h) altogether.

O.K.,o.k., so be it. ;)

> Rationale: while a "naive" Java compiler would produce a series of iload
> instructions, for reusing a local variable, an optimizing compiler or a jit
> would completely remove this.  So, yes, the code that reuse a local 
> could be
> a little slower on a interpreter (I am sure that on sablevm this would be
> negligible as iload is a very cheap operation), but good software 
> engineering
> is the goal here.

Here's the latest version:

a) toString output should begin with the name of the class

  Rationale: When a field is declared as having an interface type, or a 
non-final class, it is useful to know the exact type of the instance.

b) the rest of the string should be braced in '[' and ']'

  Rationale: Visual separation makes it easier to separate the output 
string into its type information and information about the state of the 
particular instance.

c) different instances should have different string representations

  Rationale: If two instances are not equal, then their string 
represenation should reflect that. The contents of all fields used in 
equals() should be part of the string representation of an instance.

d) fields that are used in the string representation must be named

  Rationale: Explicitely naming fields removes ambiguities when a class 
contains several fields of the same type.

e) always use a StringBuffer

  Rationale: While most Java compilers can optimize string 
concatenation by using string buffers automatically, that only works 
efficiently as long as the string representation can be generated within 
a single expression. If that's not the case, for example when iterating 
over a collection, most Java compilers create unnecessary temporary 
objects. Using a StringBuffer ensures that toString() works efficiently.

f) don't use toString() on non-primitive fields

  Rationale: Calling toString() can fail if a field's instance in null, 
resulting in a NullPointerException being thrown inside toString(). 
Since toString() is usually used to provide debugging information, it 
must not fail. Using StringBuffer.append(Object) handles null 
automatically. So simply use StringBuffer's append method for 
"field_name=" and the field instance.

g) don't write special code to handle fields being null

  Rationale: follows from f).

Example code:

public class Test{
  private String field_1;
  private int field_2;

  public String toString() {
    StringBuffer sb = new StringBuffer("Test[field_1="));

    sb.append(field_1);
    sb.append(",field_2=");
    sb.append(field_2);
    sb.append(']');

    return sb.toString();
  }
}

comments are welcome, as usual.

cheers,
dalibor topic