5 ms·
Intentionally build a style. Keep it stable for a period of time. Finally critique and improve it. You often hear "The worst code I have ever seen is code I w
by stonemetal 10y ago
Intentionally build a style. Keep it stable for a period of time. Finally critique and improve it.
You often hear "The worst code I have ever seen is code I wrote six months ago" While on the one hand that may be true, on the other hand it is trite bullshit. If the depth of your introspection and reflection on past code is "Wow what a pile of shit!". Guess what you are going to be saying about your code in six months?
With a real honest critique you will see flaws and things that you did well. Don't just dwell on what doesn't work. When you see things in your code that work well try to figure out why they work well so that it can guide your deliberate changes to what doesn't work. Also if you don't keep your style constant for a period of time you won't have enough experience with it, nor a large enough body of code to review to have a full view of what works and what doesn't.
Last but most important read the code of others to pick up ideas on how to improve your style of coding. Some of the best bits of my coding style I have picked up from others.
- kzisme 10y agoWhen you refer to style what sorts of aspects are you looking at? Simple things like bracket placement, naming conventions?
- rabidrat 10y agoIt's all kinds of things. I recently read a suggestion that you should be able to remove everything from a function's source except the declaration and the comments, and still know exactly what it does. I'm thinking about adopting that stylistic choice, and after a few weeks/months come back to reevaluate if it's worthwhile or overwrought. Or it will just be so obviously great that it becomes a permanent part of my stylekit.
- mlvljr 10y agoThis would be contracts given in plain text, only possible with very explicit comments for the whole system (and not select functions), if it all, it seems :)
- stonemetal 10y agoBy style I mean it closer to writing style. How you express your thoughts. For example checking preconditions and returning an error in a block up front instead of mixed in with the computation, or nesting your computation in a bunch of precondition if checks. Bracket placement is trivial and can be formatted with a tool in a second or two so play around with that all you like.
- maxxxxx 10y agoIt's not only about formatting or naming. It's about how you break down the problem. I sometimes write functions for a certain problem and later realize that I have written the same thing 3 years before. When I compare the code it's almost the same. Almost same function name, same parameters, same result type.