Tuesday, October 25, 2016

Do you really need instanceof?

Using instanceof is a code smell. I think we may agree on that. Whenever I see a construction like that I’m sure that something went awry. Maybe someone just didn’t notice a problem when making a change? Maybe there was an idea, but it was so complex that it required so much effort or time that a developer made a decision not to do it? Maybe it was just laziness? Who knows. The fact remains that the code evolved into such state and we have to work with it.
Or maybe there is something that we can do about it? Something that will open our code for extensions?

Tuesday, October 11, 2016

Brace yourself for a new blog design

As you probably noticed I have slightly changed the design of my blog. I hope you like it and it’s more visually appealing than the previous one. I would be more than grateful for your comments regarding the change. Is it better? Worse? Or maybe something is missing?

I also added new subpages.
On the first one, you can find some information about me and contact details which may, some time, come in handy.
On the second one, there is a list of conferences and talks where I will have (or already had) pleasure to talk and share my ideas. You may find there also a links to slides and videos.

I hope that all changes are steps in the right direction.
I encourage you to write comments and share your ideas or suggestions. If there’s something that you would like to find here - simply leave a comment. It may help me refine the blog even more.
Don’t hesitate, write your opinion and help me improve.

Friday, October 7, 2016

Pair Programming for the rescue!

Those of you who’ve already read some of my articles have probably noticed that I’m sort of a developer that is extremely passionate about code that is clean. The reason behind this fanaticism is not my fascination with pure beauty because I’ve never treated code as art as such. I’m so much focused on writing clean code and maintaining code readability because ... I’m a really lazy person.
I just think that code that is easy to understand makes my (and not only my) work easier. I don’t have to spend tremendous amount of time going over the code and seeking answers to my questions.

Monday, September 26, 2016

Want to talk?

It’s been awhile since my last article. I want to assure you that writing is still on top of my list of priorities. Recently I was just overwhelmed by lots of activities that are extremely important for me. All of them required some effort and preparation but I think that I’m almost ready to come back to writing. So expect more really soon!

Friday, July 15, 2016

Many parameters and lost information

The less code, the better? The fewer objects, the better? Is it true? As usual, it depends.

There are cases when by adding something more we are adding unnecessary complexity. It happens when we are creating interfaces or other abstractions just because “we may need this additional flexibility in future”. It happens when we forget about YAGNI principle and we are writing code that may make our life easier in case of new requirements that… may never come.

Wednesday, July 6, 2016

Implementation, behavior and the amount of the code...

Implementation, behavior and the amount of the code... Today is the right time for another code-related question that I’d like to ask.
Take a look at these methods:



To make everything clear, we can easily assume that each invocation is done in a different place and after different activities have been completed.
There is nothing exciting in this code and probably you saw something similar in your code bases many times. Nothing complicated. We are just changing the state of the object.

So, now’s the time for the question: what’s wrong with this code?

Friday, June 17, 2016

Conjunctions we... hate

Recently I’ve written about implementation-related names and I’ve presented a few examples where the method name was incorrect because of its strong relation with the body.
At one moment, we had the following code:
boolean isComplexOrUnreadableWithTests() { 
    return (complex || unreadable) && tests.exist(); 

Just to remind you of the context: it was supposed to find out whether we may or may not do the refactoring:
if (code.isComplexOrUnreadableWithTests()) {

Recently I’ve told you that the name is wrong because of its direct relation to the implementation. However, this is not the only problem. The use of conjunctions in the method’s name is a sign that we could not find a right name and we just list all known things that we’ve done. It does not matter whether this list is implementation- or logic-related.