The Myth O Is For Object (part 2)
Though the code is fictional its characteristics unfortunately aren’t. You’ve most likely encountered code like this before plenty of times. In your code base, here in @forrst, over at github in startups and large corporations. It has no boundaries. You most likely wrote something like this yourself in the past. Why do you keep writing it?
You struggle as you make an effort to understand it. Align with it as you go back and forth. Trying to digest it all at once. Don’t blame you. This code is hard to follow. The fact that you don’t know the problem is trying to solve doesn’t make it any easier. Can you even tell what the business domain is?
How much time did it take you to write it? Go back and read it again. Can you tell now? Again. How much time did it take you to understand it? Now go away and come back tomorrow. Read it again. Do you still remember what it does? How much time in total do you think it takes everyone reading that code to understand it? How much time will it take you to extend it? To maintain it? To test it. Can you test it? It will only get messy. You want to throw it away. How much time will it take you to write it again? How much time have you wasted?
Ask yourself. What’s wrong with it? It must be something really great this code is doing. Why else would it look that horrible?
Code doesn’t have to look like that.
This isn’t about not knowing what problem is trying to solve. Nor how complicated it might be.
int type = 1;
even mean? How is this related (if so) to
String string = "business";
All you can tell is that 1 leads to
case 1: System.out.println("Flying down to " + to + " from " + from + " in " + string + " class on " + dateFormat.format(date.getTime()));
You have to follow all that code down to switch just to find out what it means. Looking back, you knew right there when you made the choice, you don’t need that switch! But there is only that much you can do with an int in an OO world.
Like that string. With a no clear cut relationship between that and the type. Will changing one break the other? Is it relevant? How do you enforce their relationship?
What about all that unrelated code that you have to move out of the way to get a clear picture of what this is all about?
Writing code isn’t subjective. It’s about software design.