Robert Martin

Originally posted by Kuldeep Yadav:
Hi Robert,



But that lead to thousands methods in single class.

Is it then clean code ? Also calling number of method will completly destroy
abstraction of you code. isn't it ?

First, you'd better not have thousands of methods in a single class. If you do, your classes are too big. Classes should have a few dozen methods, and less than a dozen variables.

Secondly, no, it doesn't destroy abstraction to have lots of little methods. Indeed, it greatly enhances abstraction. The reason is simple. When you have big methods you will almost certainly find stretches of duplicated (or nearly duplicated) code. When you break those methods into many smaller metods, you consolidate that duplicate code into single small methods. Code size can actually shrink significantly!

But that's only part of the issue. The real issue is that when you break big methods up into smaller ones, you are _organizing_ your code. You are creating places to put things, and then putting them away properly.

Remember when your mother would tell you to clean your room? You thought the big messy pile of clothes and toys was perfect because you knew where everything was. It was in your room in the big messy pile. Your mother showed you how to put everythign away in the right drawers, shelves, and closets.

Big functions are like dirty rooms. They are big piles of functionality without sufficient organization. Clean your room and keep it clean. Break your small functions up into lots of little functions.

Originally posted by kelahcim kela:
Hello Robert,

as far as I can see your book is available through the Oreilly's Safari on-line catalog. Do you plan to publish it as a PDF as well?

Prentice-Hall is the publisher. Check with them about PDF versions.

Originally posted by kri shan:
We have been writing the code two years, now we are thinking of adding comments for most of the logic instead of adding the code comments during coding. Is it good idea ? What is the risk of adding code comments after too many code deliveries to the customer.

The risk is that you will comment dirty code rather than clean it. Your FIRST priority is to make sure the code is clean and easy to read. Only after you have tried to clean a module, and failed to get it to express itself, should you comment it.

Of course this only works if you have tests that allow you to safely clean the code. You _do_ have such tests don't you? You'd better!

Originally posted by Adeel Ansari:
Is there any emphasis on continuous inspection in the book. I mean how we should practice this. Or may be best practices or something?

Indeed there is. The idea is simple. We should constantly and continuously improve our code. The book talks about the "Boy Scout Rule" which is that we should always check our code in just a bit cleaner than when we checked it out.

Originally posted by Ilja Preuss:


What name would you you give to a thread-safe hibernate implementation of a DAO for Administrator instances?

;-) Since all classes should be thread safe, I would simply call it AdministratorDAO. I would put the ThreadUnsafe prefix on it if it wasn't thread safe....

Originally posted by Ilja Preuss:


Mhh, yes... but - you will still have to catch BaseException, too, because that is what the interface declares. Of couse you know that it can't be thrown, but unfortunately, the compiler doesn't.

Mhh, just remembered that you prefer RuntimeExcptions. Problem solved.

[ September 25, 2008: Message edited by: Ilja Preuss ]

The following code seems to work fine.

public class C { public static void f() throws E { throw new E1(); } public static void main(String[] args) { try { f(); } catch (E1 e) { // do right thing. } catch (E2 e) { // do right thing. } catch (Exception e) { // complain bitterly. } } } class E extends Exception {} class E1 extends E {} class E2 extends E {}

Originally posted by Tomasz Prus:
TDD question: How should i test domain classes when they have only getters and setters, what can i test? I heard that testing field accessors is nonsense.

Don't test classes that have nothing but getters and setter. Don't HAVE classes that have just getters and setters. Such classes are not classes at all -- they are data structures and their variables should be public.

Yes, I know there are "bean" standards. (Sigh). OK, so if you have to conform to a silly standard like that, go ahead and make your getters and setters. But don't test them.

Oh, and read the "Data" chapter in "Clean Code".

Originally posted by Rogerio Kioshi:
Hi,

Many times we get some application whose code is not very well written, but the application is working fine.
Do you think is it a waste of time refactoring something like this, if the whole application was written in a way you consider not so clean?

Thank you.

It is not a waste of time to refactor ugly code. You don't want to turn that refactoring into a whole project of it's own however. Rather, every time you touch that code, you should clean a little bit of it. Every time you check it in, make sure it's cleaner than when you checked it out. (This is the "Boy Scout Rule").

Originally posted by Adeel Ansari:
May we say this book is sort of a new version of Martin Fowler's Refactoring?

No, not at all. Martin's book (a wonderful book by the way) is about the details of the process of refactoring, especially in environments where the tools won't help you.

The Clean Code book does not try to tell you how to manipulate the code at a low level. Rather it tells you what the code should look like, and how to identify code that looks wrong.

Originally posted by Radoslaw Zubek:
I have problem with some way of encapsulating boilerplate code. To avoid writing some part of code for http requests and responses each time, I decided to encapsulate it in one method. This method gets only query string and listener for response.

void performRequest(String queryString, ResponseListener listener) {...} ... interface ResponseListener { void httpResponse(int status) throws BaseException; }

My problem is, that I have to throw a various exceptions depends on 'status' variable and this exceptions are thrown through 'BaseException'.

public void doSomeWork(String params) throw DerivedException1, DerivedException2 { try { performRequest(params, new ResponseListener() { public void httpRequest(int status) throws BaseException { switch (status) { case 0: /* ok */ break; case 1: throw new DerivedException1(); case 2: throw new DerivedException2(); default: throw new RuntimeException("status: " + status); } } }); } catch (BaseException e) { if (e instanceof DerivedException1) { throw (DerivedException1) e; } if (e instanceof DerivedException2) { throw (DerivedException2) e; } } }

My question is how to avoid this ugly code for casting exceptions and encapsulate some boilerplate code.

Catch the exceptions by their true type!! Don't catch the base and then downcast. Yes, this means you'll have many catch clauses. That's better than having a set of instanceof statements...

Originally posted by Tomasz Prus:
What about such class names like "ThreadSafetyAdministratorHibernateDAO", is it good? Sometimes there is really problem

I guess it depends on whether that class is the Hibernate implementation of the DAO that has the CRUD functions for ThreadSafetyAdministrator instances.

If not, then I think that name could probably use a bit of work.

Originally posted by Tomasz Prus:
I heard from someone such advise to use everywhere interfaces where it is possible. Is it good to extract always interfaces or should i do it just when i need it?

You should only do it when you need to. Of course if you follow the disciplines of Test Driven Development, you'll need to all the time. ;-)

Originally posted by Paul Wallace:
Hi,

What do you consider the essential "agile toolkit" that a developer should use, for example:

Dependency Injection - to enable mock objects to be inserted into unit tests, what DI frameworks would you consider?
Testing Frameworks?

What else?

Regards,

Paul

The best agile toolkit is a good brain and a disciplined attitude. The rest is just gravy. Of course I really like IntelliJ as an IDE. Eclipse is pretty good too. And I use JUnit and Emma.

Dependency Injection is useful, but I hate all the XML files. (XML is God's way of punishing us for writing ugly code. ;-)

I like JMock, but use it sparingly since heavy use of these mocking tools leads to very fragile tests.

Originally posted by Joshua Smith:
Martin-

In my place of work we have some green fields code, but a lot of it is inherited. Does your Clean Code book describe how to handle legacy code or does it assume you're architecting from the ground up?

Thanks,
Joshua Smith

Neither. It's simply a guide for transforming ugly code into clean code. The book has several examples, some small, and one reasonably large, of that kind of transformation. The book also sets for a set of traits that clean code has.

Originally posted by greg fuentes:
Does clean code involve "Programming to an interface" and keeping methods as Generic as possible?

Sure. At lease that's good clean design. But clean code is a lot more than just programming to interfaces. It's clean names, small functions, well partitioned classes, minimal comments, and a whole host of other practices.