Eclipse line shortcuts

You can only have one thing in your clipboard, right ?

So you end up having to paste somewhere temporarily to avoid overwriting your clipboard content…you lose time and you mess up your files with temporary pastes that you forget to clean up…

There are other ways. If you want to clone a block of lines and move it somewhere nearby, proceed this way:

  1. Select the block of lines by pressing Shift + Arrow up/down.
  2. Press Ctrl + Alt + Arrow down, this will clone the block of lines.
  3. Move the lines where you want them: Alt + Up/Down.

You may still think copy & paste is faster, but notice how these shortcuts are similar, if you put your fingers on Alt and Ctrl and the up/down arrows you can combine them very quickly. It gets even faster for a single line.

In addition to that I would recommend using Ctrl + D for quickly removing lines and Ctrl + Shift + C to comment/uncomment lines. There are many other shortcuts,  but it does not make much sense to list them without giving a use case, simply press Ctrl + Shift + L.

There are various Multi clipboard tools/plugins, but I do not like depending on those.

Conclusion

This is very similar to copy & pasting, but it allows you to keep your clipboard content where you would normally not. These shortcuts can prove very effective when combined.

Related posts

Book review: Effective Java, Second Edition

I bought this book (at Eyrolles) about one month ago and nearly went through all of it.

Book cover

Book cover

http://java.sun.com/docs/books/effective/

The author, Josh Bloch, is writing code from an API designer’s perspective. It is not easy to view everything from this perspective at first, but after reading most of it APIs will become more transparent when used and you will even save precious time when writing your own.

My favorite chapters are:

  • 4. Classes and interfaces
  • 6. Enums and Annotations
  • 8. General Programming

Some chapters may not be crucial, like the one about serialization, but other chapters are worth reading for everyone.

Because you can read chapters in any order you will probably find this book easy to read. My approach is to read a chapter and apply what I have read, then I go on reading another one.

Conclusion

What struck me is that this book is a must read for intermediate java developers because it goes beyond mere Java syntax and gives some advice that is valid for any object-oriented language. You will keep coming back to it while programming, so keep it close.

Work towards the compiler

This is the first post !

You may think that you know what you are doing because it is your code after all, but if a mistake can be done it will be done (when refactoring or by someone else modifying your code).

This post illustrates how easy it is to write error prone code, but also how little effort it may take to reduce the danger.

Equals method:

Consider the following code sample:

package javarizon;

import java.util.ArrayList;
import java.util.List;

public class TypeSafeEquals {
 public static void main(String[] args) {
 final String one = "1";
 final int oneAsInt = 1;
 final Object object = "1";

 // Compiles...
 one.equals(oneAsInt);

 // First idea: It works, but if you pass an object by mistake it still
 // compiles. Have fun debugging !
 one.equals(String.valueOf(oneAsInt));
 one.equals(String.valueOf(object));

 // Better idea: It works, but will not compile if you use an object.
 one.equals(Integer.valueOf(oneAsInt).toString());
 one.equals(Integer.valueOf(object).toString());

 // Even better: it only takes an int.
 one.equals(Integer.toString(oneAsInt));
}
}

The first version is often used because it easy to come up with, but if you accidentally use a bad parameter, it will compile and not even break at runtime: it results in a bug that will be difficult to spot.

It might even work by chance in some cases (there are only two possible return values) depending on your application logic and data. Imagine you use such non-type safe code everywhere in your code, you or someone using your code is doomed to make a mistake at some point.

In the second version, the chances of committing a mistake were drastically reduced simply by using code that will accept less types, it does not compile when passed an object:

The method valueOf(String) in the type Integer is not applicable for the arguments (Object)

Consider using code completion on a method to quickly check what types it can take, if there are too many (especially evil Object) try looking for a more restrictive alternative. You could also write a static method that takes two Strings and uses equals internally, the only problem is that you have to do this for every possible type.

Conclusion:

Being careful is not enough, when properly helped the compiler is much more careful than you ever will. Always strive to maximize type-safety when writing code. Ensure the compiler is on your side by adapting your programming style to it.

I will try coming up with more examples in the future posts.