Fail fast. Check input and fail on nonsensical input or invalid state as early as possible, preferably with an exception or error response that will make the exact problem clear to your caller. Permit "innovative" use cases of your code though (i.e., don't do type checking for input validation unless you really need to).
This is is BS.
Fail fast with a exception most likely ends up into a giant trace track no one even understand what is happening. It most likely will confuse the guys that uses it and waste their times endlessly. I know this from experience when services goes down yet again and no one understand what the hell did it this time.
I have developed tens of millions of lines of code the last decades and this is the single source of problems that completely cripples your production environment. It most likely causes cascading failures because you create a system that is unstable and unpredictable.
Yes yes I know someone will probably say: "but but, the error should be clear". I have news for you: The code that makes this fault clear is probably going to be bigger than the function that it is supposed to do. And worse of it, the error reporting most likely is going to be a new source of faulty behavior.
Fail fast is NOT a best practice. It could be useful under certain condition but not a rule of thumb.
Also from security point of view, fail fast also means that you expose coding towards hackers. It gives them clues to find out what ticks under the hood.
Make code correct first and fast second. When working on performance issues, always profile before making fixes.
This is good advice. First make sure your code works. Code in such a way that the code is readable. It is the only way to have a baseline to compare to to see if the speed increase is actually increased.
However improving speed is normally done by redesigning the work-flow and code flow. Optimizing one method means nothing, you have to do it for the complete library. e.g. it is pointless to have too many parallel threads if you bottleneck is that single hard disk. Your other threads stalls waiting for that single thread to complete.
I recently saw a guy modify my code in what he thought would be faster. He used this giant linq statement. I asked other developers what this code is doing. They saw nothing wrong. I told them that no one knows what this code will do. It "appears" correct but you are at the mercy of the compiler, the library that will execute that Linq statement and worse it could create massive parallel network requests that will bring down the network.
Don’t do work in object constructors, which are hard to test and surprising.
Good advice. I would even say that constructors should only contain code that is fast and will not fail.
If you have additional code that needs to be executed that could fail or will take time then use a separate method that may be named "Initialize()"
When your constructor only contains code that cannot fail, you always end up into a "known" state. Not a partially initialized state that take sup too much code to free up resources and detect what has initialized and what failed.
4 comments
1 u/roznak 24 May 2017 23:07
This is is BS.
Fail fast with a exception most likely ends up into a giant trace track no one even understand what is happening. It most likely will confuse the guys that uses it and waste their times endlessly. I know this from experience when services goes down yet again and no one understand what the hell did it this time.
I have developed tens of millions of lines of code the last decades and this is the single source of problems that completely cripples your production environment. It most likely causes cascading failures because you create a system that is unstable and unpredictable.
Yes yes I know someone will probably say: "but but, the error should be clear". I have news for you: The code that makes this fault clear is probably going to be bigger than the function that it is supposed to do. And worse of it, the error reporting most likely is going to be a new source of faulty behavior.
Fail fast is NOT a best practice. It could be useful under certain condition but not a rule of thumb.
Also from security point of view, fail fast also means that you expose coding towards hackers. It gives them clues to find out what ticks under the hood.
1 u/roznak 24 May 2017 23:20
This is good advice. First make sure your code works. Code in such a way that the code is readable. It is the only way to have a baseline to compare to to see if the speed increase is actually increased.
However improving speed is normally done by redesigning the work-flow and code flow. Optimizing one method means nothing, you have to do it for the complete library. e.g. it is pointless to have too many parallel threads if you bottleneck is that single hard disk. Your other threads stalls waiting for that single thread to complete.
I recently saw a guy modify my code in what he thought would be faster. He used this giant linq statement. I asked other developers what this code is doing. They saw nothing wrong. I told them that no one knows what this code will do. It "appears" correct but you are at the mercy of the compiler, the library that will execute that Linq statement and worse it could create massive parallel network requests that will bring down the network.
0 u/roznak 24 May 2017 23:25
Good advice. I would even say that constructors should only contain code that is fast and will not fail. If you have additional code that needs to be executed that could fail or will take time then use a separate method that may be named "Initialize()"
When your constructor only contains code that cannot fail, you always end up into a "known" state. Not a partially initialized state that take sup too much code to free up resources and detect what has initialized and what failed.
0 u/Fatima_005 13 Aug 2017 09:22
Geat Article @www.way2testing.com