Start from details-write clean and clear code

Start from details-write clean and clear code by pp_psy

Details are as important as architecture!

Two words, clean, must be harsh and clean

Do you sometimes want to read your own code? Have you ever changed your requirements?

Have you ever seen hundreds or even thousands of lines of code? Have you ever read some code that contains variables or methods such as A1, A2, and A3? Do you like to read the code of some people when you work with colleagues? Do you dare not read the code of some people? Have you ever met a colleague whose code will not be taken over if he leaves?

I once thought it was an architecture problem, an experience problem, or a technical level problem. I spent a lot of time studying the framework. I think a beautiful framework can solve all problems, unfortunately, this was far from enough.

Let's leave the design and architecture aside for the moment. Here we only talk about one word, which is clean!

Be sure to fight for cleanliness!

I hate chaotic and unordered code, and the lessons are so painful. Here I want to borrow the words from famous writers in the book "The neat way of code.

I like elegant and efficient code. Code logic should be straightforward, making defects difficult to hide; reduce dependencies as much as possible to facilitate maintenance; improve error handling code based on a hierarchical strategy; optimize performance, it is easy to lure others into optimization with no rules and create a pile of chaos. Clean Code only makes one thing better.

-Bjarne stroustrup, C ++ language inventor

 

Clean code is simple and straightforward. Neat code is like a beautiful prose. The clean code never hides the intent of the designer, and is full of clean abstraction and straightforward control statements.

-Grady booch, author of Object Oriented Analysis and Design with applications (Object-Oriented Analysis and Design.

I have no intention of conceptual plagiarism, but I added some requirements to the code when I summarized the development last year, this requirement should be handed over to my colleagues and new personnel in the future group as the basic specification for project team development. At this time, I got into touch with the book "The clean way of code", and I felt a little overwhelmed. The basic requirements have been modified. Now, let's take a look. This is my pure subjective idea. If you have different opinions, we are welcome to discuss it.

1. name. The name is a comment.

Use the hump method, such as dosomething

Class Name: uppercase letters

Method Name: lowercase letters in the header

Int I is allowed in local sub-methods, but in common methods, it must be written as int xxxindex

Temporary variable name tmpxxx

Then, if you find that the name is incorrect, or later you find that other naming methods are better, use the project name modification tool to modify

2. Method (function)

The method name must be annotated. If necessary, add a method annotation. If ide permits it, it must be the annotation that someone else can see directly when referencing your method (here, I will explain it, remember that you can add/** xxx */annotation to the function in Java. In this way, this annotation prompt will be provided when the method prompts. xcode and mono both have the type function)

One method only does one thing. Try to do this. If a method does more than N things, split it.

A method cannot contain more than 100 rows. A normal method can contain less than 50 rows (this requirement is already very broad). If it is larger than 100 rows, it can be split. If there is no time, you can find time to split it by yourself.

In the method, the relevant code is written together. Do not leave blank lines.

Good indentation, which is not mandatory here. One of the two kinds of indentation is used according to your habits.

Private methods must be private and should not be seen (OC is implemented by category)

Use multiple code group tools and add clear comments

(In xcode, the # define mark XXX annotation is used to group methods)

(The mono tool in unity3d is # region XXX annotation # endregion)

3. Notes

If the name can be annotated, do not comment

If you have to make comments, try to make comments that can be directly seen when others call them.

Every member associated with other classes of the class is annotated.

If a comment is out of date, delete or modify it.

// For the above 1, 2, 3 for all team members

4. About the framework

Try to do only one thing or one thing for each class.

Less inheritance and more combinations

High Cohesion in class, low coupling between classes

UI and data are separated, if there is enough time

5. refactoring

The only thing that remains unchanged is changes. This is especially true for game development. When appropriate, we propose restructuring.

Frequent, multiple times, and time-consuming refactoring

6. About Cooperation

Let everyone have a systematic concept. Do not do this part today, or do it tomorrow.

Cooperation especially requires code readability and must be made readable by others.

If you are a programmer and do your own code well, if you are in charge of many people, let everyone write their own code, and then you write a clear interface

When talking about requirements with planning, we should try our best to clarify the requirements. When we start to do this, we should draw a picture in the white class, so that developers can clearly understand the design ideas and what everyone should do.

The dominant factor is the rejection of dependency-related questions. This attitude should be known to the people who ask questions at the beginning.

7. About warning

When developing programs in xcode, the code written by myself, 0 warning, third-party, and warning, can be processed to single digits, or all

In many cases, changes in demand and time pressure will make a very clean start project a mess, There is no shortcut, in addition to the attention on the details, it is re-built over and over again. I personally think that most of the time in the project is to maintain the Code, rather than writing new code. Since maintenance is required, the code that can be viewed at a glance is the best, in addition, the team cooperation will not limit the readability of the Code, especially when it comes to people who are smart, often self-directed, and lazy. The Basic specification must be followed, and this habit will also help programmers to move farther and farther. Every reconstruction is a reincarnation Nirvana, and the pain is only known by people who are in it. Most of the time, they are done by themselves at the end of work.

To add one point, the ROAR said that all this is about micro-Operations. As for the architecture, it is a question of the overall situation. The Dota, Warcraft, or Starcraft players will certainly understand this. I'm pretty much confused.

Original article, reprinted Please note:Reposted from devdiv blog

Link:Starting from details
-Write clean and clear code