You are on page 1of 2

How can scroll blindness be mitigated?

Daniel erbnescu 05/15/12

Scroll blindness-free Programming Template for Java


The purpose of this temple is to reduce the so-called effect of scroll-blindness when
programming in Java. If you arrange your methods in a predetermined order you will
always know where your methods are.

In order to avoid scroll-blindness, your Java classes should be like this:


package name;
import declarations;
class definition;
field declarations;
constructors;
abstract methods:
static methods;
object-related methods;
accessors methods;
overridden methods from super class;
overridden methods from Object class;
run() or main(String[] args]) method;

About overridden methods from Object class


Since the most used methods are in the following order:
1. String toString()
2. the pair int hashCode() and boolean equalsTo()
I would recommend to use a bottom to top order of these methods as follows: String
toString() - the most bottom one, closely followed by boolean equalsTo() and hashCode(),
afterwards Object clone() and void finalize()

About overridden methods from Super class


Usually hey should follow the same order as in the super class; however in case you are
extending an older class and you feel uncomfortable with method's order you should
think about repositioning the methods in the older class or in case you don't have
explicit access to it, you can just reorder the methods as you think it's suitable for you,
after all it's for your own sake.
Licensed under GNU Public License v3

Page: 1/2

How can scroll blindness be mitigated?

Daniel erbnescu 05/15/12

About accessor methods


Everyone is familiar with methods like Object get() or set(Object o) . I suggest to keep
those methods in pair whit the get() method before the set(); and for a really clean an
ordered class you should think about maintaining the order of get-set pairs the same as
the order in which fields are declared

About documentation
I think that you should keep the documentation as far away from your code as possible,
that does not mean that you should not write documentation!
Most of the documentation could be placed inside interfaces and abstract classes and be
referred to the abstract class' documentation as follows:
place this block of comments on top of your method implementation:
/* (non-Javadoc)
* @see package.AbstracClass#abstractMethod(parameter)
*/

Do NOT use documentation comments, use slash-star comments (not slash-star-star)


As you get used to this you might ommit the non-Javadoc note to decluter a bit your
code. In most IDEs you can even leave no documentation for overridden methods and
you will still be able to get the documentation from the abstract method on your screen.
The main rule here would be:
Avoid writing documentation on for your implementations methods unless is really
needed. Write good documentation for your abstract methods.

Licensed under GNU Public License v3

Page: 2/2

You might also like