Comment Re:Linux kernel (Score 2) 373
1 Handles errors gracefully.
This statement always hits me as mind numbingly stupid. In general try / catch and other error managing statements are for the lazy that don't want to understand the environment and inputs well enough to write the proper code to manage them. You want rock solid code that will last for years, eliminate the errors, don't "handle them gracefully". The only exception to this rule should be when the native environment forces it upon you or there is a lack of some proper check "doesThisReallyExist()".
By errors I meant where paths and files don't exist, the user or external software sends bad info or someone runs or the machine runs out of resources. Case in point: someone edited one of our databases in a place I used to work and some software crashed hard when it grabbed a NULL value from the database leaving me to check the core dump to discover the problem.
2. Only reinvents the wheel when there is a measurable benefit in doing so..
I learn more reinventing the wheel and there is no substitute to working with code you are sure of and know how it's going to perform.
I agree with the rest.
I can see wanting to learn.. I can't see duplicating system libraries in a project. Some libraries (Libc in particular) have whole groups of programmers who are rather good at squeezing every last drop of speed out of the implementation, there are also things such as leap year handling that look simple but end up being harder than they look.