Quora Feeds
Active Member
Carey Gister
All of the answers here are excellent but I would like to reiterate a few of them:
1. Not commenting your functions, methods, classes and algorithms because you think you will have time to do it later. You won't. And even if you do, the comments won't be as meaningful as they are when you write them BEFORE you write the code you are going to document.
Code might be 'obvious' (a subject for another day), but the reason WHY you made the choices you made is not obvious except in the most trivial cases.
2. Hardcoding constant values and strings rather than making them macros, static data items, constants, default values, parameters or properties (look up technical debt: Technical debt)
3. Reinventing the wheel. When an implementation is available from a well established source, use it rather than writing it yourself. In some cases there may be legal reasons for not doing this, such as the code you want to use is under a non-permissive reuse license or requires a fee you are not willing to pay, but in many cases you can find a free to use and free to redistribute version.
4. Preferring clever code over clear code. It is harder than it seems to make things simple to understand. A common metric is that at least 80 per cent of a piece of codes life will be spent in maintenance. Odds are very good that if the code is successful that you will not be the one maintaining it. Make your successors job easier. Pay it forward. Be clear rather than clever.
See Questions On Quora
Continue reading...
All of the answers here are excellent but I would like to reiterate a few of them:
1. Not commenting your functions, methods, classes and algorithms because you think you will have time to do it later. You won't. And even if you do, the comments won't be as meaningful as they are when you write them BEFORE you write the code you are going to document.
Code might be 'obvious' (a subject for another day), but the reason WHY you made the choices you made is not obvious except in the most trivial cases.
2. Hardcoding constant values and strings rather than making them macros, static data items, constants, default values, parameters or properties (look up technical debt: Technical debt)
3. Reinventing the wheel. When an implementation is available from a well established source, use it rather than writing it yourself. In some cases there may be legal reasons for not doing this, such as the code you want to use is under a non-permissive reuse license or requires a fee you are not willing to pay, but in many cases you can find a free to use and free to redistribute version.
4. Preferring clever code over clear code. It is harder than it seems to make things simple to understand. A common metric is that at least 80 per cent of a piece of codes life will be spent in maintenance. Odds are very good that if the code is successful that you will not be the one maintaining it. Make your successors job easier. Pay it forward. Be clear rather than clever.
See Questions On Quora
Continue reading...
