1. it will require your least of time to understand when you come back to your code in future (more than 6 months)
2. it can be easily debugged, maintained, extended and modified.
About Writing Perfect Code:
You may attempt to write perfect code if:
1. You have lots of time
2. You are not doing a real-world production project
3. You are doing it for research and study purpose
4. You are doing it as a hobby
Other than that, writing perfect code is a never ending attempt. There is no perfect, it's simply does not exist. What you should focus on is the stability and reliability of the code. Make sure the code does what it has to be done.
Your clients rely heavily on your software to solve their problems.
You have to make sure your code runs stable enough and can be easily maintained.
I agree. For production code I would prefer something up until the switch-refactoring. The factory stuff is an overkill because it obscures the simple logic with several classes. The businees relevant logic is spread across the whole class system. But its true, that this is a good code solution like stated by adriancs.
The factory stuff is an overkill because it obscures the simple logic with several classes.
This is true for this simple example. A friend of mine several years ago here in the U.S. was coding financial calculations that varied according to state laws, and contract options. A switch statement with 50+ cases just for the states and territories, and then another switch in each case to handle the contract options would have quickly led to insanity! He used a separate class to implement each state, and a factory to instantiate the appropriate class, and it made life much easier. Rather than obscuring the simple logic, it actually allowed him to clearly focus on one state at a time.
Yes, there are times that you don't completely normalize a database... there are times that you don't resort to factories and strategies. You don't write a factory when there can only ever be two cases. But for anything that is even a bit complex, these techniques will pay huge dividends down the road.
I totally agree. In the real world writing good code often means to find a good balance between "perfect code" and "functional" code.
Especially regarding point 1 and 2 that you have mentioned.
I can not tell the number of times I was told to "just make it work, the customer expects this to run tomorrow", which is a totally different problem related to management... but it does happen, doesn't it?
From my point of view, this (above) article is not suitable for new fresh learners.
This (above) article is for anyone whom starts to write a real program, especially for those who work in a team.
The article has convey 2 messages.
First, the rules and guidelines of writing code.
Second, which is the most important part... The reason (purpose, target, destination) why you need to apply these guidelines and follow the rules.
Rules and guidelines are somehow good. It is the outcome of someone's years of experiences. They walk through all the hard time, the failures. They summarized and came out with the standard advise for others to follow, with the wish that others will not make the same mistakes.
Rules and guidelines, are mostly very specific.
It's like a guidelines for you to reach a destination.
You have to go Road A, turn left, Go to Street B, then turn right, go to Road C...
It's like a guidelines to design a proper building...
A single door should design with [A cm width x B cm height]
A path way should be [C cm width]
The window should design with [D cm width x E cm height]
It's like a guidelines to draw a picture...
The sun will be in Orange and Yellow color
The grass will be in green color
The sky will be in blue color
All these guidelines are good.
It tells you the common sense and by following the rules, you will achieve some results in a shorter time.
When you continue to move on, you will gain your own real experiences. More and more practices...
when the skills start to become part of your soul, those guidelines and rules that you once learned, hold for long time will now become obstacles to you.
It will restrict your imagination...
It will limit your creativity and invention...
It will prevent you from discoveries...
and you when start to jump out from the all these rules....
You will have more potentials to discover new possibilities.
something you never thought this before but it just happens...
It is like Christopher Columbus showed how to make an egg stand.
Programming is an art.
A young child should not be taught how to draw picture. Let them drawing freely without style restriction.
And it is same here, the reason why I mentioned earlier in this post, this (above) article is not suitable for new fresh learners. Let them focus on the logic and functionality of code, learn the coding style later.
Thanks for the well constructed and informative article, Radoslaw. Could I suggest that your AddDiscount method name is misleading? It is not adding the discount, it is subtracting it. I would have thought that ApplyDiscount and SubtractDiscount are more appropriate names. Regards, George.
While looking at naming - enums should really be singular - so AccountStatuses should be AccountStatus ... looks better when using the enum. And it is also sensible to always have an enum value for the default value an enum will get when declared - which is zero - so adding and handling AccountStatus.Unknown (set to 0 in the enum) is recommeded.