Contents
Should you comment every line of code?
Comments should be very rare and valuable, almost always expressing the “why” and never the “how” (the exception being when the how is complex and not easily discernible from the code). Every comment is a hint that you may need to refactor to make the code’s intent clearer.
What is the recommended comment to code ratio?
The ideal comment / code ratio is 0.
How detailed should code comments be?
Comments should be useful high level descriptions of what the program is doing. They should not restate something that is “obvious”. By using appropriate variable names, much of a program can be (almost) as easy to read as English.
When does a code do not need a comment?
“is each line of the code – in its context – either self-explanatory enough that it does not need a comment, or if not, is it accompanied by a comment which closes that gap? Or (preferably) can the code be changed so it does not need a comment any more?”
How to improve the quality of legacy code?
Refactor Legacy Code (When Necessary) One way to improve the quality of an existing codebase is through refactoring. Refactoring legacy code can help you clean up your codebase and lower its complexity. The best way to improve a legacy codebase is to do it gradually.
Can you add best practices to coding standard?
If you start adding all kinds of “best practices” to the coding standard, you will just end up repeating which is already stated in multiple books. Just buy “Clean Code”, “Code Complete” and “The Pragmatic Programmer” to the developer in question, and keep your coding standard lean.
Can you buy clean code, code complete, and the Pragmatic Programmer?
Just buy “Clean Code”, “Code Complete” and “The Pragmatic Programmer” to the developer in question, and keep your coding standard lean. It is not possible. What you are essentially trying to do is nearly to mechanize good judgment.