I make up the thinking programming rules for my team: what do you have?

Question

For some time I worked on a list that helps me use the why approach to programming and think about how , how to do something.

For this, I wanted to create a list of things that:

• best practice
• the best thought
• better approach ...

which help the programmer to effectively analyze, think, approach, solve and implement in the most efficient way.

I saw dozens of incredibly valuable comments on Stack Overflow questions, but I couldn't find a place where we keep them together. There is the most controversial opinion about Stack Overflow. However, I’m just looking for insightful ideas that can be shared and help my team, and I’m better suited and solve problems by improving programming.

I hope this can be one place to collect one or two airliners, which are short, deep and easily accessible, repeated, viewed. If we stick to one rule for each answer, it may be easier to vote up / down.

I'll start with the first one.

DRY - don't repeat yourself - in code, comments or documentation.

Answer 1

Always leave the code a little better than when you found it.

Answer 2

The code does not exist until it is entered into the version control system .

Answer 3

Do not be afraid to admit "I do not know" and ask.

10 minutes asking someone to save the day by pulling your hair out!

Answer 4

Do not reinvent the wheel

If there should be a function in the main library, perhaps there is.

Answer 5

KISS - Keep it simple, stupid.
Choose the simplest solution that works .
Don't make things (too) complicated before they should be.
Just because everyone else uses a complex structure to solve their problem does not mean what you need.

Answer 6

Useful is important.

Enter the code as if the person who ends his maintenance will be crazy and know where you live.

Answer 7

Someone else will not fix it.

If the problem comes to your attention, take possession long enough to ensure that it will be taken care of anyway.

Answer 8

Do not optimize if there is no obvious problem.
Most of the time, when people try to optimize the code before it is necessary, they will spend a lot of resources, make the code more difficult to read and maintain, and will not achieve a noticeable effect. Sometimes they even get worse.

"We have to forget about little efficiency, say, about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

Answer 9

How difficult is it?
Do not let any problem bully you.

Answer 10

Don't Collect Requirements - Dig for them

Requirements rarely lie on the surface. They are buried deep beneath layers of speculation, misconception and politics.

via Pragmatic Programmer

Answer 11

Follow the principles of SOLID :

Single Responsibility Principle (SRP)

There should never be more than one reason for changing a class.

Open Closing Principle (OCP)

Software objects (classes, modules, functions, etc.) must be open for expansion, but closed for modification.

Liskov replacement principle (LSP)

Functions that use pointers or references to the base of classes should be able to use objects of derived classes without knowing it.

Network Separation Principle (ISP)

Clients should not depend on interfaces that they do not use.

Dependency Inversion Principle (DIP)

but. High-level modules should not be affected by low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

Answer 12

I think that almost everything that is indicated in the section "The Zen of Python" applies to each list of "Rules of Mindset". Start with "python -c" import this ":

Zen Python, Tim Peters

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• The complex is better than complex.
• Flat is better than nested.
• The relief is better than dense.
• Readability indicators.
• Special cases are not complicated enough to break the rules.
• Although practicality surpasses purity.
• Mistakes should never pass silently.
• Unless explicitly disabled.
• In the face of ambiguity, give up the temptation to guess.
• There should be one — and preferably only one — an easy way to do this.
• Although this path may not be obvious at first, if you are not Dutch.
• Now better than never.
• Although it’s never better than now.
• If implementation is hard to explain, this is a bad idea.
• If the implementation is easy to explain, this might be a good idea.
• Namespaces are one good idea - let me do more!

Answer 13

Best Practice: Use Your Brain
Do not follow any trend / principle / pattern without thinking about it

Answer 14

Test Driven Development (TDD) makes encoders sleep better at night

Just to clarify: some people seem to think that TDD is just an incompetent encoder that can limp from A to B without getting too tight, and if you know what you are doing, it means that there is no need (units) of testing . This completely overlooks Test Driven Development. TDD is about three (update: apparently four):

• Refactoring magic . Having a complete set of tests means that you can do crazy refactoring tricks by manipulating the entire structure of your application without missing any of the two hundred crazy subtle side effects that can arise from this. Even the best programmers are reluctant to reorganize their main classes and interfaces without good (single) test coverage, because it is almost impossible to track all the small “wave effects” that it causes without them.

• Detection of early traps . If you write tests correctly, it means getting you to consider all cases of fringe. Often this leads to a better design choice after the start of the actual development, as the encoder has already considered some of the more complex situations that may require a different inheritance structure or a more flexible design pattern. The need for these changes is often not obvious - or intuitively - during the initial planning and analysis, but these precise changes can make the application much easier to extend and maintain the line.

• Providing test writing . TDD requires you to write tests before writing code. Of course, this can be a pain in the ass, since written tests are tedious compared to writing real code - and often it takes longer. However, this is the only way to ensure that tests are written at all. If you think that you must write tests as soon as the code is executed, you are almost always mistaken.

• Making code write better . Since TDD forces all the code to be tested (you don't write the code before it checks it), it requires that you write more loose code so that you can test the components separately. Therefore, TDD makes you write better code. (Thanks, Esco)

Answer 15

Google before asking your colleague and interrupting his coding.

Answer 16

Less code is better than more if it makes more sense than a lot of code.

Answer 17

The habits of a lazy coder

The first time you are asked to do something, do it (on the right).

The second time you are asked to do this, create a tool that will do this automatically.

And the third time, if the tool does not cut it, create a domain-specific language to create additional tools.

(should not be taken too seriously)

Answer 18

Be the catalyst for change

You cannot force change on people. Instead, show them how the future could be and help them participate in its creation.

via Pragmatic Programmer

Answer 19

Do not panic when debugging

Take a deep breath and THINK! about what might cause the error.

via Pragmatic Programmer

Answer 20

You can copy and paste to make it work, but you cannot leave it.

Duplicated code is an intermediate step, not a final product.

Answer 21

It’s both what you say and how you say it

It makes no sense to have great ideas if you do not communicate them effectively.

via Pragmatic Programmer

Answer 22

Always write the code as if the person who ultimately supports your code is a cruel psychopath who knows where you live.

From: horror code

Answer 23

Post early, publish frequently

Answer 24

Build a keychain for lunch

Answer 25

Build it right first. Make it second.

Answer 26

Review code frequently

Code verification, and therefore refactoring, is an ongoing task. Here are some helpful code review guidelines in my opinion:

• Improves code quality.
• It helps to reuse reusable codes in reusable libraries.
• It helps you learn from your fellow developers.
• It helps you learn from your mistakes and update the memory of the genius code you wrote earlier.

Answer 27

Anything that can affect how the application works should be considered code, which means that it must be in version control. Scripts and databases and data files (.sql) are especially built.

Answer 28

Configuration convention

Especially where agreements are strong and flexibility can be sacrificed.

Answer 29

Participate in open source development

If you use the source code in your projects, be sure to post corrections and improvements to the community. This is not the best development practice as such, but it is definitely the mindset of a programmer to strive for.

Answer 30

Understand the tools you use

Do not use the template until you understand why you are using it; do not use the tool without knowing why; Do not rely on your framework or language designer, which is always suitable for your situation, but also do not assume that they are mistaken until proven!