[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The right way(tm) of writing toString() (Was: Re: [PATCH] Field position
From: |
Dalibor Topic |
Subject: |
The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling) |
Date: |
Sat, 29 Nov 2003 20:03:08 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 |
Hi Mark,
Mark Wielaard wrote:
Hi,
On Sun, 2003-11-23 at 21:40, Dalibor Topic wrote:
2003-11-23 Dalibor Topic <address@hidden>
* java/text/FieldPosition.java (equals): Fixed comment.
Looks fine. Please check it in.
It would be nice if we had something about the right way (tm) of writing
the standard clone(), toString(), hashCode() and equals() in the Hackers
Guide. (hint...)
I see. I'll try to come up with something based on what I've seen on the
web and Bloch's book.
here's my attempt at writing a short passage on the Art of Writing
toString methods. As everyone has written bazillions of them, it's a
perfect subject for bikeshed type of discussions. Feel free to chip in
with your own bits of wisdom ;)
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) use '+' to concatenate strings and objects
Rationale: Most Java compilers can optimize string concatenation by
using string buffers. There is no need to do that task by hand. Using
'+' allows you to write simpler code.
f) don't use toString() on non-primitive fields. Use "field_name=" +
field instead.
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 '+' as explained above lets the compiler do the job
of calling StringBuffer.append(Object) or String.valueOf(Object), that
both can handle null automativally.
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() {
return ("Test
+ "[field_1=" + field_1
+ ", field_2=" + field_2
+ ']');
}
}
comments are welcome, as usual.
cheers,
dalibor topic
p.s. if performace of toString() doesn't matter that much, and we can
use reflection, it would be quite simple to write a
gnu/classpath/ToString class with a stringize method that could
automatically create string representations conforming to above rules,
given the interesting fields of a class.
it basically comes down to:
stringize(Field [] fields)
getClass().getName()
+ '['
+ ( for all f in fields : f.getName().toLower() + '=' + f.get() +
separator(", "), if necessary)
Is there some interest in that?
- [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/15
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/15
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/18
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/18
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/18
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/19
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/23
- Re: [PATCH] Field position attribute handling, Mark Wielaard, 2003/11/25
- The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling),
Dalibor Topic <=
- Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Etienne Gagnon, 2003/11/29
- 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), David Lichteblau, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), David Lichteblau, 2003/11/30
- Re: 2nd attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Etienne Gagnon, 2003/11/30
- 3d attempt at Re: The right way(tm) of writing toString() (Was: Re: [PATCH] Field position attribute handling), Dalibor Topic, 2003/11/30
- Re: [PATCH] Field position attribute handling, Tom Tromey, 2003/11/18
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/18
- Re: [PATCH] Field position attribute handling, Dalibor Topic, 2003/11/19