Lua code writing specifications

Lua code is written in specifications

In development, a large number of use of lua, temporarily according to the current situation, sum up the relatively good specifications, in multi-person collaboration can be better development, communication.

Introduced

The purpose of this document is to establish coding guidelines for writing applications using lua.
The purpose of coding specifications:

• Unified coding standards, common, improve development efficiency;
• Make your code easy to understand and maintain.

Remember: Make good use of the debugger.

First, naming conventions

1． All lua files are named with lowercase letters and underscores

2． Class names and variable names use meaningful English as much as possible, class names use Pascal nomenclats, and variable names use camel-style nomenclats

3． Constants, message numbers are defined in capitals, and between words are split eg:KIND_PET_FOOD

4． W hen enumeration values are defined, prefix enum_

5. Function names use camel-style nomenclats

Note:

Camel-style nomenclat: The first single word begins with a lowercase letter;

Pascal nomenclat: Much like camel nomenclat, only one difference is that the initials are capital letters. (No space breaks or connection numbers between words)

Second, the organization of documents

1. A brief description of the functions and responsibilities of the document is added at the beginning of the document;

As follows:

--

-- Author: Feng

-- Date: XXXX-XX-XX

-- Feature description

Each file has a module qualifier; the imported module has a local qualifier; or it can be used (module (..., package.seeall) for thermal updates

2. All external functions provided are annotated in the following format.

For example:

--This function detects whether you can walk from point A (oldx, oldy) to point B (newx, newy)

--@param oldx is currently at point x

-- @param oldy is currently at point y

-- @param newx target point x

-- @param newy target point y

-- @return if you can reach it, return to true;

function Object:checkBar(oldx, oldy, newx, newy)

...

end

3. Add empty lines between the function and the function, as well as some definitions.

4. Temporary variables within the function, and local functions in the file are added to the local qualifier

5. When the number of lines of a function is too long (greater than 100 lines), try to split into sub-functions;

6. Short comments are used --;

7. The assert function is not a small overhead, please use with caution.

8. When lua classes are designed, the oop is implemented with meta-tables.

Do not add function members directly, because adding function members directly results in increased memory and no difference between execution efficiency and meta-tableing under jit.

9. The document is in UTC8 format

Separation and indentation

1. Use empty lines

Separated by blank lines on a single line in the following cases:

1) Between methods

2) Between the logical paragraph sections of the code inside the method

3) Before the comment line

Add one or more empty lines before the comment.

2. Use space characters

In addition to separating names with space characters between normal components, such as between data types and variable names, a space character should also be used to separate them in the following cases:

1) between the operator and the operator, e.g. c s a s b;

2) After the comma in the parameter list, such as:

function m1(year, month)

end

3) At the time of the for statement, such as:

for k, v in pairs(t) do

end

4) Do not use spaces in the following cases.

For example:

When the function is defined:

function test1(a)

end

Don't do this:

function test1( a )

end

When the function is called:

test1(3)

Don't do this:

test1( 3 )

The reason not to do this is that:

a) Easy to forget the relevant spaces, resulting in a different style, so it is better not to;

b) .lua parsing syntax is parsed with segmentation such as spaces, and in some cases accidentally addition of spaces can lead to uglier results.

3. Use line breaks

It is not recommended to write more than one statement in a line, which should be newer when the length of a statement typically exceeds 80 characters

4. Use parentheses

You can use parentheses to force the order of operations

5. Use indentation

Indentation is applied in the following cases

1) The ingredients in the class

2) The component in the method body or statement block

3) Non-starting lines when newer

The reduction is generally to run to the next watch-making position on the basis of the previous level of composition

Fourth, code recommendations:

1． S ome of the functions used in the code are redefined with the local prefix at the beginning of the file or in the current local environment.

For example:

local assert = assert

2. Minimize that the members in the table are references to another table. C onsider lua's garbage collection mechanism, memory leaks, and so on.

3． A dvanced features are not used as much as possible

4． W rite as simple as possible when writing code, and when considering performance, make inferences to see how much you can improve, increase the complexity, and how obscure the code is, and then decide what to do

5． L oaded xml data table, as far as possible to do a good job of data verification, if the check fails, to start assertion, so that the server can not start;

6． W hen something goes wrong, log the error.

Some function overhead is relatively large, and the frequency of calls is very low, then he can not be optimized;

Conversely, some functions are less expensive, but the frequency of calls is high, from how to reduce the frequency of calls and reduce the cost of functions to think about two angles, and then set the optimization scheme

Remove or comment out unrelated code before submitting code;