-2
\$\begingroup\$

There are some unfortunate habits most beginners — and even some experienced! — programmers make. For example, in Python it is common to not know about PEP8 standard, or include if __name__ == "__main__":. When addressing these common mistakes answers/comments should ideally include a link with additional information. And since these type of mistakes occur so frequentl I thought that it might be useful to collect some standard replies for quick copy&paste.

I think the best structure would be one answer addressing general tips for improving code, while each additional answer should address common bad habits in a particular answer.

See for instance LaTeX meta - Text building blocks or Mathematics meta - Generalizations of commonly asked questions for some similar metaposts in our sister communities.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ The trouble with cut+paste reviews is that they often seem dissociated from the code under review (i.e. no specific quotes from the question code) and aren't well adapted to the varying experience levels of askers. \$\endgroup\$ Jun 9 at 8:54
  • \$\begingroup\$ @TobySpeight The point is to supplement the codereviews with general principles. In your code you did X, however a common practice is Y (links to Y). See for instance how I addressed the PEP8 issue in my review here. These snippets should be building blocks one use in the review, not the entire review. \$\endgroup\$ Jun 9 at 8:56
  • 3
    \$\begingroup\$ I have closed your question, not because I think the idea is bad. However we've had plans in the past to do something similar, and your proposition doesn't seem like anything new. The best bet is probably to integrate your efforts with Loki on GitHub. \$\endgroup\$
    – Peilonrayz Mod
    Jun 9 at 9:18
-1
\$\begingroup\$

General

### Keep your code DRY

_DRY_ stand for "_Don't Repeat Yourself_", a basic principle of software 
development aimed at reducing repetition of information. The DRY principle 
is stated as, "Every piece of knowledge or logic must have a single, unambiguous 
representation within a system."

To avoid violating the DRY principle, divide your system into pieces. 
Divide your code and logic into smaller reusable units and use that code 
by calling it where you want. Don't write lengthy methods, but divide 
logic and try to use the existing piece in your method.

Less code is good: It saves time and effort, is easy to maintain, and 
also reduces the chances of bugs.
\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .