Development specification code naming rules for PHP programs

Naming rules in the code: wrong and correct comparisons

Programming beginners always spend a lot of time learning programming languages, grammar, techniques and programming tools for use. They thought that if they mastered the technical skills, they would be good programmers. However, the purpose of computer programming is not about mastering these technologies or tools, it is about creating solutions to specific problems in specific areas, and programmers working together to achieve them. So, it's important that you need to be able to express your thoughts exactly in code, so that other people can understand your intentions through the code.

Let's take a look at the words in clean Code from the Masterpiece Robert C. Martin, Master of programming.

The purpose of the annotation is to compensate for the lack of expression in the code itself. ”

This sentence can simply be understood as if your code needs comments, most likely your code is very bad writing. Similarly, if you cannot fully express your idea of a problem or an algorithm without a comment, then this is a signal of failure. In the end, this means that you need to use annotations to illustrate some of the ideas, which are not visible in the code. Good code allows anyone to read without needing any comments. a good coding style can contain all the information that helps to understand the problem in the code.

In programming theory, there is a concept called "self-describing source code". For a piece of code, a common self-describing mechanism is to follow some non-strictly defined variables, methods, object naming rules. The main purpose of this is to make the source code easier to read and understand. Therefore, it is easier to maintain and expand.

In this article, I will cite some examples of what is "bad code" and what is "clear code"

Name to be able to expose

How to name it is always a problem in programming. Some programmers prefer to simplify, shorten, or encrypt names so that only they can understand them. Let's look at some examples:

Bad code:

int d;//days int ds;int dsm;int faid;

"D" can mean anything. The author uses annotations to indicate his intentions, but does not choose to express them in code. and "Faid" can easily lead to misunderstanding as ID.

A clear code:

int elapsedtimeindays;int dayssincecreation;int Dayssincemodification;int fileageindays;

Avoid misleading information when naming

The wrong information is worse than no information. Some programmers like to "hide" some important information, and sometimes they write some misleading code.

Bad code:

Customer[] customerlist; Table thetable;

The variable "customerlist" is actually not a list. It is an ordinary array (or a collection of customers). In addition, "thetable" is a table-type object (you can easily discover its type with the IDE), and the word "the" is an unnecessary distraction.

A clear code:

Customer[] Customers; Table customers;

Name to have the right length

In high-level programming languages, the length of variable names is usually less restrictive. Variable names can be almost any length. Even so, it can make your code feel like a annoyance.

Bad code:

var thecustomerslistwithallcustomersincludedwithoutfilter;var list;

A good name should contain only the necessary vocabulary to express a concept. Any unnecessary words can make the name longer and harder to understand. The shorter the name the better, the premise is to be able to express the full meaning in the context (under the order of the scene, "Customersinorder" is better than "list").

A clear code:

var allcustomers;var customersinorder;

Name-time coding specifications are consistent, allowing the specification to help understand the code

All programming techniques (languages) have their own "style", called coding specifications. Programmers should follow these habits when writing code, as other programmers know and write in this style. Let's look at a bad code example with no obvious specifications. The following code does not follow well-known "coding specifications" (such as Pascalcase, CamelCase, Hungarian specifications). Worse, there is a meaningless "change" to the BOOL variable. This is a verb (to describe the action), but here the bool value is to describe a state, so it should be more appropriate to use an adjective.

Bad code:

const int Maxcount = 1bool Change = Truepublic interface Repositoryprivate string Namepublic class Personaddressvoid Getal Lorders ()

A piece of code, just look at its part, you should directly understand what it is, just look at its naming method.

For example: You see "_name", you can know it is a private variable. You should take advantage of this representation anywhere, with no exceptions.

A clear code:

const int MAXCOUNT = 1bool ischanged = Truepublic interface Irepositoryprivate string _namepublic class Personaddressvoid Getallorders ()

The same concept of naming is expressed in the same words

Defining concepts is difficult. In the software development process, a lot of time spent in analyzing business scenarios, thinking about the correct definition of all the elements. These concepts are always a headache for programmers.

Bad code:

1.void loadsingledata () void fetchdatafiltered () void Getalldata ()//2.void setdatatoview (); void Setobjectvalue (int Value

First of all:

The author of the code tried to express "get the data" concept, he used multiple words "load", "Getch", "get". A concept can only be expressed in one word (in the same scene).

Second:

The term "set" is used in 2 concepts: The first is "Data loading to view" and the second is "setting a value of object". This is two different concepts and you should use different words.

A clear code:

1.void getsingledata () void getdatafiltered () void Getalldata ()//2.void loaddatatoview (); void Setobjectvalue (int Value

Use words related to the business domain when naming

All the code written by the programmer is connected to the business domain scenario logic. In order for all people concerned with this problem to understand better, the program should use a meaningful name in the domain environment.

Bad code:

public class entitiesrelation{entity O1; Entity O2;}

When writing code for a field, you should always consider the name of the domain that is associated with it. In the future, when another person (not just a programmer, perhaps a tester) touches your code, he can easily understand what your code means in this business area (no business logic knowledge required). The first thing you should consider is business problems, and then how to solve them.

A clear code:

public class productwithcategory{entity product; Entity category;}

Use words that are meaningful in a given environment when naming

The name in the code has its own context. Context is important for understanding a name because it provides additional information. Let's take a look at a typical "address" context:

Bad code:

String addresscity;string addresshomenumber;string Addresspostcode;

In most cases, "Post code" is usually part of the address, and it is clear that the ZIP code cannot be used alone (unless you are developing an application that specializes in postal code). Therefore, there is no need to add "address" in front of "postcode". More importantly, so this information has a context-tolerant environment, a namespace, and a class.

In object-oriented programming, this address information should be expressed in an "address" class.

A clear code:

Class address{string city;string homenumber;string postcode;}

Summary of naming methods

To summarize, as a programmer, you should:

Naming is to express the concept of

Note the name length, the name should only contain the necessary words

The coding specification helps to understand the code, and you should use it

Name don't Mix

The name is meaningful in the business domain and meaningful in the context.

