classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

3d attempt at Re: The right way(tm) of writing toString() (Was: Re: [PAT


From: Dalibor Topic
Subject: 3d attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling)
Date: Sun, 30 Nov 2003 19:20:50 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]