4 ms·
I've been reading other devs code for about two decades now. Universally all the code I see is not quite up to the standards I have for "good code" though some
by InclinedPlane 8y ago
I've been reading other devs code for about two decades now. Universally all the code I see is not quite up to the standards I have for "good code" though some of it is better than others. Most devs give up on getting better writing code too easily, or more importantly they focus on the wrong things. There is always room for improvement no matter how good you are.
Focus on making your code clearer, not fancier or "faster". Don't prematurely optimize your code by eye. Generally just being conscious of the major performance no-nos to avoid and being able to use appropriate tools (like a profiler) when and if you actually need to tune performance is all you need. Instead concentrate on making your code highly readable, self-documenting plus fully documented (the best of both worlds!), as well as composable and maintainable and you'll be well set. Not just will you make other developers happy and improve the code base overall (fewer bugs, easier modifications for inevitable feature changes in the future) but you'll make your future self happier when you have to come back to that code.
By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. And getting into the habit of making little functions that just take a few inputs, do stuff, and return a value makes your code way easier to unit test as well.
- Kabootit 8y ago> Focus on making your code clearer, not fancier or "faster". Exactly! > By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people As a general rule this is just one side of the coin imo. I often see this approach increasing the complexity of control flow in direct proportion to the simplification of individual code blocks. Net gain zero.
- badpun 8y ago> Extract your methods people, it's not that hard and it's a great habit to get into. It takes skill to get good at it but a decently named small function makes code more readable and more reliable. For me it actually makes code less readable. It makes the system more complex (because you've added extra function definitions and function calls) and just jumping back-and-forth between those small function calls makes code harder to read. I would much prefer to have a larger method that just does things in order, and, for readability, have its body divided into sections, each in isolated brackets (so that variables have local scope) and commented if necessary.
- zawazzi 8y agoI think all humans are bounded by 7+/-2 chunks of working memory which I think correlates to upper bound of understandability. Personally I break up methods where I see more than 5-7 unique params/variables/concepts. Also usually co-locating related methods will help which is what OOP does.