... about why evil is considered harmful

In last year's Build Stuff conference, Uncle Bob ranted that we, as software developers, don't adhere to any rules or standard. A few weeks later, he repeated that claim in a blogpost:

And yet nothing binds us together as a profession. We share no ethics. We share no discipline. We share no standards. We are viewed, by our employers, as laborers. We are tools for others to command and use. We have no profession.

I like uncle Bob very much. He's the only one I know that has been warning and continues to warn us about the way we treat our own industry.

Don'ts and don'ts

I'm a java developer. Personally, I don't have the feeling that we share no standards. My world is full of them. Rules, principles, standards and things a developer cannot, should not do. They're not explicit, but implicit. Still, those rules exist. Here's a list of some of them:

1. fat controllers are bad
2. mutable data is evil
3. premature optimization is the root of all evil 
4. goto considered harmful 
5. static is bad 
6. duplicate code is evil
7. if statements are evil
8. null references are the billion dollar mistake
9. getters and setters are evil
10. extends is evil
11. dependency injection is evil
12. frameworks are evil
13. ...and the list goes on... 

All those rules are really just opinions and they are there for a very good reason. Those opinions are explained in detail and are stated in a certain context. The rule survives the passing of time, the reasons behind them, for most of us, don't.

The heretic

Here's another one. It must have been about the first rule I learned when starting programming in java. A little while ago I was pairing with a colleague and created a class that was used as a data container, a dto. I created the class and made all fields public. It looked something like this:

public class Employee {
    public final EmployeeId id;
    public final String firstName;
    public final String lastName;
    public final Email email;
    public Employee(EmployeeId id, String firstName, String lastName, Email email){

        ....
    }
}

There you have it. I broke one of the oldest rules in java development: Never create public fields! Always keep your fields private and create public getters. 

My colleague looked at me with a strange look. He didn't have the energy to start a discussion with me and didn't say anything, but I could tell he was thinking I was doing a very, very bad thing.

Nevertheless, there is no reason why I would add all those extra intellij-generated lines of useless getter code. The class is not part of any api nor will it ever be. There's no information hiding necessary. It's just a data structure that contains certain data in a strongly typed way. By leaving out the getters, the class remains concise, clean and maintainable. 

But, public fields are evil! Evil, I say!

The point is... people forgot the reason why that rule exists. They only remember the rule. The fact that it's evil. Truth is (=my opinion), in a lot of our code, there's no reason to hide information. Especially when it's immutable (which is another one of my rules).

Saying something is evil or considered harmful is a great way to create a meme, but it's detrimental in the long term when you forget the reason why.

Greetings,
Jan