Redundant Variables Are Pure Evil

  • 396 words
  • two minutes to read
  • comments

A redundant variable is one that exists exclusively to explain its value. I strongly believe that such a variable is not only pure noise but also evil, with a very negative effect on code readability. When we introduce a redundant variable, we intend to make our code cleaner and easier to read. In reality, though, we make it more verbose and difficult to understand. Without exception, any variable used only once is redundant and must be replaced with a value.

Need Robust Software? Make It Fragile

  • 555 words
  • three minutes to read
  • comments

In any software project, the goal is to create something stable. We don't want it to break in front of a user. We also don't want our website to show an "internal application error" instead of a web page. We want our software to work, not fail. That's a perfectly valid and logical desire, but in order to achieve that, we have to make our software as fragile as possible. This may sound counter-intuitive, but that's the way it is. The more fragile your app is in development, the more robust it is in production.

Why Many Return Statements Are a Bad Idea in OOP

  • 258 words
  • a minute to read
  • comments

This debate is very old, but I have something to say too. The question is whether a method may have multiple return statements or always just one. The answer may surprise you: In a pure object-oriented world, a method must have a single return statement and nothing else. Yes, just a return statement and that's it. No other operators or statements. Just return. All arguments in favor of multiple return statements go against the very idea of object-oriented programming.

Nine Steps to Start a Software Project

  • 2113 words
  • 8 minutes to read
  • comments

Agile or not, a software project starts with a requirements analysis and definition. We basically define what needs to be done somehow, be it on a piece of napkin or a 100-page Word document. The next step is to turn this into a working piece of software as fast as possible and by spending as few dollars as possible. Ideally, this prototyping takes a week and is made by an architect working solo. Once the "skeleton" is ready, we start putting software "meat" on it. We recruit a team of programmers for that or outsource it. I see nine important steps in the skeleton creation part; let me show you them one by one.

Checked vs. Unchecked Exceptions: The Debate Is Not Over

  • 1313 words
  • five minutes to read
  • comments

Do we need checked exceptions at all? The debate is over, isn't it? Not for me. While most object-oriented languages don't have them, and most programmers think checked exceptions are a Java mistake, I believe in the opposite—unchecked exceptions are the mistake. Moreover, I believe multiple exception types are a bad idea too.

Hourly Pay Is Modern Slavery

  • 613 words
  • three minutes to read
  • comments

What is the difference between a slave and a free man? A slave has a master. That master, a cruel and ruthless villain, is telling the slave what to do and punishing him at will. However, at the same time, the master guarantees food and a roof over the slave's head. A slave understands this exchange of freedom for food as a fair trade, while a free man values freedom more. That's the difference. That's how it was in the Roman empire centuries ago. But isn't that how it is now too? Aren't we ancient slaves in our offices and in front of our monitors?

Fools Don't Write Unit Tests

  • 564 words
  • three minutes to read
  • comments

"We don't have time to write unit tests" or "We don't have the budget for unit testing" are complaints I hear very often. Sometimes it may sound like, "We don't use TDD, so that's why there are no unit tests," or even "TDD is too expensive for us now." I'm sure you've heard this or even said it yourself. It doesn't make any sense to me. I don't get the logic. In my understanding, unit testing is not a product; it's a tool. You use tests to develop a product faster and better. How can you say you don't have time to use the tool that makes your work faster? Let me show you how.

Meetings Are Legalized Robbery

  • 2142 words
  • 8 minutes to read
  • comments

Software development is all about creativity, right? It's an art, not a science. As software engineers, we solve complex problems, and often our solutions are absolutely not obvious. We experiment, innovate, research, and investigate. To do all this, we talk. We sit together in our meeting rooms, Skype conference calls, or Slack channels; we discuss our solutions; we ask our coworkers for their opinions; and we argue about the best ideas. There's no doubt meetings are the key component of the modern software design discipline ... and it's very sad to see it.

Catch Me If You ... Can't Do Otherwise

  • 612 words
  • three minutes to read
  • comments

I don't know whether it's an anti-pattern or just a common and very popular mistake, but I see it everywhere and simply must write about it. I'm talking about exception catching without re-throwing. I'm talking about something like this Java code:

try {
  stream.write(data);
} catch (IOException ex) {
  ex.printStackTrace();
}

Public Static Literals ... Are Not a Solution for Data Duplication

  • 557 words
  • three minutes to read
  • comments

I have a new String(array,"UTF-8") in one place and exactly the same code in another place in my app. Actually, I may have it in many places. And every time, I have to use that "UTF-8" constant in order to create a String from a byte array. It would be very convenient to define it once somewhere and reuse it, just like Apache Commons is doing; see CharEncoding.UTF_8 (There are many other static literals there). These guys are setting a bad example! public static "properties" are as bad as utility classes.