Calling all Java Gurus

it can be less easy to see the full intent of the code by just looking at it, with active objects, event handling, etc.

Possibly but you should still be able to make sense of a single class/component without knowing the full context of the system. If you can’t then that suggests it is poorly designed, doesn’t follow SOLID principles and will be a maintenance headache later in the life-cycle.

I’ve code reviewed everything from ARM assembler and bit-bashed I2C drivers in C, up to enterprise applications in Java, C++ and C#. If someone needs to take my hand to lead me through it then it is crap code.

welcome to the world of off-shoring where variables and comments come in a variety (usually jumbled together) of languages.

I’m not a geek, that’s why I’m good at my job

You must be a geek otherwise you would not recognise the word and I must be less of a geek as, although I recognised the word, I could not spell it correctly 🙂

If someone needs to take my hand to lead me through it then it is crap code.

they are not leading you through the code that is in front of you, they are responding to questions about how the system works. You could sit there looking for all references to that object/method and work it all out, but having a more interactive session is more time efficient. With everyone under time pressure nobody wants to sit there for hours pondering over some code listings, and they won’t. And there is little point human readers repeating what an automatic tool or compiler setting could achieve.

Anyway, with TDD styles the important thing is public interfaces, not necessarily the underlying code which may be put together in less than ideal conditions to met the next deadline, and will be refactored afterwards. The tests prove that, although the code is sub-optimal, it meets it goals – and that is what you want after all.