The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

Lessons from the Google Web Toolkit…

I’ve been looking at the sample projects from the Google Web Toolkit. Mostly looking at code and playing around with the apps. Based on this, I think I can learn couple things from the toolkit and the source they provide.

First of all, if you have not looked at the code, it might be a good time to do now (by downloading the tookit, you will have everything under the samples directory).

I love the samples’ code style. I love its simplicity.

If I was an architect for a code style document, I would adopt the following things:

Simple, small classes. It’s a joy to look at them; they’re easy to understand and thus, I think, easy to modify.

Small methods. Show me a method that’s over 100 lines. I’d like to see it. The way they built the framework, the abstractions they have, allows them to have small methods. This is a key to having maintainable code.

Using intefaces a lot. Using inheritance. It allows them to keep their classes small, highly specialized.

Self-commented code. They don’t use too many comments. They use self-commented code. The source speaks for itself. That’s beauty.

A one sentence summary of what the class does. If you can’t fit it in one sentence, it means that you don’t have a good class. It should probably be renamed, broken up, refactored. But this one sentence should always be there.

Comments to explain more complex code. Writing self-commenting code is crucial, but not always possible. Adding a comment where it helps is important.

Not going over 80-character margin. I’ve been trying to do that (in Eclipse you can set a visible margin at 80 – search for “margin” in preferences). It makes the code more readable.

Having 2-character tabs. I like that. The code looks better. Plus, you can fit more into 80 characters.

Effort put into making code readable. I can’t stress this enough. Put your name on the code, make it look good, make it elegant. Your code is your public face to other programmers, believe it or not.

I think it’s important to have a mindset that a quality code is a requirement (and an asset).

P.S. One thing I did not like is the package structure. They just put everyting into one big package. Not the optimal way, I think, but maybe they did not want to expose too much.