提供英文文档

CppCXY · CppCXY · commit 6bbbfb0489c4 · 2021-12-16T11:17:03.000+08:00
diff --git a/README_EN.md b/README_EN.md
@@ -0,0 +1,46 @@
+# EmmyLuaCodeStyle
+
+If possible, you can help me improve the English document 
+
+## Project Introduction 
+
+This project is an example of Lua code analysis\formatting\code diagnosis algorithm library and language service based on C++
+
+The main pursuit of this project is reasonable formatting and diagnosis of various code styles
+
+In addition to providing language service examples, the project also provides an independent command line tool CodeFormat, which can be used for batch code formatting and code style checking (there are still many problems, you can modify it yourself). 
+
+## 文档
+
+* [Introduction to formatting behavior](docs/format_action_EN.md)
+* [How to configure formatting](docs/format_config_EN.md)
+* [Code diagnosis configuration](docs/diagnosis_config_EN.md)
+
+# Contribute
+
+Any pr or issue are welcome 
+
+## Build
+
+If you want to compile the project yourself, make sure that your compiler can basically support C++20: 
+* VS2019 16.10以上
+* gcc 10以上
+* clang 10以上
+
+```
+mkdir build && cd build
+cmake ..
+cmake --build . 
+
+```
+
+## Developed By
+
+[**@CppCXY**](https://github.com/CppCXY)
+
+**Contributors**
+
+
+## License
+
+no License
diff --git a/docs/diagnosis_config_EN.md b/docs/diagnosis_config_EN.md
@@ -0,0 +1,107 @@
+# Diagnostic options
+
+Most of the formatting options have diagnostic attributes. In addition, there are additional options for diagnostics. These options do not affect formatting.
+## enable_check_codestyle
+
+Whether to enable code diagnosis The optional value is true/false.
+
+## max_line_length
+
+Represents the maximum line width detection. This option does not affect formatting. The default value is 120.
+
+## insert_final_newline
+
+This option indicates whether the Lua document should end with a new line. The name of this option comes from the standard definition of editorconfig. The default value is true. The code formatting algorithm must end with a new line, so this option is only used for diagnosis.
+
+# Naming style check
+
+The algorithm supports basic style checking for the name definition, and the more complex verification logic can be opened after the plug-in system is designed. All check logics can be represented by'|' or' operation. The basic check logic includes:
+* off do nothing
+* camel_case little camel case nomenclature
+* pascal_case big hump nomenclature
+* snake_case snake nomenclature
+* upper_snake_case snake nomenclature in all uppercase
+
+The complex verification logic is expressed in the form of a function:
+1. same(arg1, arg2) This form means that the form of arg2 is the same as arg1. The only variables supported by arg2 are:
+    * snake_case in a snake-like way
+    * pascal_case is in the form of big hump nomenclature
+    * camel_case in the form of small camel case nomenclature
+    
+    The methods supported by arg1 are:
+
+    * filename means the same as the current file name, the same way is not necessarily congruent, it can be in the form of arg2
+    * first_param means the same as the first parameter of the related calling function, and it is also allowed to act in the form specified by arg2
+    * String constant means equal to a string constant, such as same('_M'), when arg1 is a string constant, the arg2 parameter is invalid
+
+## enable_name_style_check
+
+This option is false by default, which means whether to enable naming style checking
+
+## local_name_define_style
+
+This option indicates what naming rules the names in the local name definition list should conform to. The default value is snake_case
+
+## function_param_name_style
+
+This option indicates that the default value of the parameter naming rule during function definition is snake_case
+
+## function_name_define_style
+
+This option indicates the naming rules for function definitions. The function definition referred to here only contains the following forms:
+* function fff() end
+* function ttt:ffff() end
+
+The default value of the option is snake_case
+
+## local_function_name_define_style
+
+This option indicates the naming rule when the local function is defined. The only supported form here is: local function fff() end
+
+The default value of the option is snake_case
+
+## table_field_name_define_style
+
+This option indicates the naming rule of the field of the table, and the classification may be evolved later. The currently supported forms are: 
+
+```lua
+local t = { aa = 1312}
+
+t.bbb = 123
+```
+
+The default value is snake_case, but the names of all meta-methods are not within the rules.
+
+## global_variable_name_define_style
+
+Indicates the name definition style of global variables. The default value is snake_case|upper_snake_case
+
+## module_name_define_style
+
+Indicates the name definition style of the module, and the identification rules for module variables are:
+Take the name of any local definition in the file scope as the first parameter of the return statement in the file scope.
+
+The default option is same('m')|same(filename, snake_case)
+
+## require_module_name_style
+
+Indicates the name defined in the import statement of the module. The statement recognition principle is:
+Shaped like 
+```lua
+local m = require "aaa.bbb.ccc" 
+```
+The m in the lua statement, the supported functions currently include require and import
+
+
+The default value is same(first_param, snake_case) 
+
+## class_name_define_style
+
+Represents the naming rules of class definitions. The recognition principles of class definitions are:
+Shaped like 
+```lua
+local c = class "c"
+```
+The c in the lua statement, the supported functions currently include Class and class
+
+The default value is same(filename, snake_case) 
diff --git a/docs/format_action_EN.md b/docs/format_action_EN.md
@@ -0,0 +1,240 @@
+# Introduction to formatting behavior 
+
+## Basic Statement
+
+The algorithm itself will use more reasonable principles to do basic code layout optimization:
+* All logos/keywords/literal expressions usually keep a space or relative line spacing with the next element
+* Binocular/monocular operators will keep a space with the operand or keep relative line spacing, there is no space between the comma and the previous element and the next element keeps a space
+* Short statement blocks can (but not necessarily) remain on the same line. This principle is valid for all function/do/while/repeat/if statements
+* The algorithm will not automatically interrupt a single-line statement that is too long. The algorithm seldom actively wraps. The algorithm will try to ensure that the line spacing of all elements is the same as before.
+* The algorithm does not remove any visible elements, such as semicolons. Do not format if there is a syntax error
+* The algorithm will not typeset the content of the comment, for example, all the parts of the long comment that are considered to be comments will not increase the indentation 
+
+```lua
+local t=123 --local
+aaa,bbbb = 1123, 2342
+local f =function() end
+local d = {
+    -- comment
+    aa = 213, --comment
+};
+local e = a+b+c+d
+function fff(a,b,c) end
+function ff2()
+--[[
+    long comment
+]]
+end
+```
+
+Will be formatted as:
+
+```lua
+local t = 123 --local
+aaa, bbbb = 1123, 2342
+local f = function() end
+local d = {
+    -- comment
+    aa = 213, --comment
+};
+local e = a + b + c + d
+function fff(a, b, c) end
+
+function ff2()
+    --[[
+    long comment
+]]
+end
+```
+
+## Continuous assignment statement 
+
+For consecutive assignments or local statements, when the algorithm recognizes that the code tries to align to the equal sign, it will typeset in the manner of aligning to the equal sign. The basic principle of identifying alignment is:
+    
+* For consecutive assignment/local/comment statements, when the equal sign of the first assignment/local statement is more than 1 space away from the element to its left, the consecutive assignment/local statement will be aligned to the equal sign.
+* The definition of continuous alignment here is: no more than 2 lines between statements
+* Alignment will be aligned to the furthest equal sign 
+
+```lua
+local ttt  = 123 --first
+cd        = 345 --second
+```
+
+格式化后：
+
+```lua
+local ttt  = 123 --first
+cd         = 345 --second
+```
+
+## Table layout 
+
+For common table expressions, the default formatting method is:
+* The field in the table will be spaced a blank from the braces of the table or keep relative line spacing
+* Different fields in the table will keep their relative positions unchanged
+* If all the fields are in different rows and are in the form of key = value, when different fields try to align to the equal sign, the algorithm will align to the equal sign
+* The basic principle of trying to align to the equal sign is key = value/comment field. When the distance between the equal sign of the first line of field and the element to its left is greater than 1 space, the key = value field in the table will be aligned to the equal sign 
+
+```lua
+local t = {1,2,3}
+local c = {
+    aaa, bbb, eee
+}
+local d = {
+    aa  =123,
+    bbbb = 4353,
+    eee  = 131231,
+}
+```
+
+格式化后：
+
+```lua
+local t = { 1, 2, 3 }
+local c = {
+    aaa, bbb, eee
+}
+local d = {
+    aa   = 123,
+    bbbb = 4353,
+    eee  = 131231,
+}
+```
+
+## Long expression list 
+
+If the long expression list and the long expression have more than one line, except for the first line, the remaining lines will be indented by one continuation line:
+
+For example: 
+
+```lua
+local aaa = 13131, bbbb,
+    ccc, 123131, ddddd,
+    eeee, fff
+
+return aaa, bbb, dddd
+    or cccc
+
+if aaa and bbb 
+    or ccc() then
+
+end
+
+```
+
+## Statements containing statement blocks
+
+For if statement, repeat statement, while statement, do statement, for statement and function definition statement they all have the following formatting characteristics:
+
+* When the statement containing the statement block is only one line, the algorithm will keep them in one line
+* For statements that usually contain statement blocks, there will be one more indentation in the statement block
+* The statement containing the statement block and the next statement are usually separated by at least 1 line
+
+For example: 
+
+```lua
+do return end
+function f(x,y) return x<y  end
+function fff()
+local t =123
+end
+```
+
+Will be formatted as: 
+
+```lua
+do return end
+
+function f(x, y) return x < y end
+
+function fff()
+    local t = 123
+end
+
+```
+
+## Function definition parameters and function call parameters
+
+The definition parameters of function definition statements have the following principles:
+* By default, if the definition parameter of the function wraps, it will be aligned to the first parameter after the wrap
+
+For example: 
+
+```lua
+function ffff(a, b, c,
+    callback)
+end
+```
+
+After formatting: 
+
+```lua
+function ffff(a, b, c,
+              callback)
+end
+
+```
+
+The parameters of function call have the following principles:
+* If the function has multiple parameters, if the parameter list itself changes lines, except for the first line, the remaining lines will be indented by one more continuation line
+* If the function call is a single parameter without parentheses, there will be a space between the function identifier and the parameter
+
+For example: 
+
+```lua
+print(aaa, bbbb, eeee, ffff,
+ggggg, hhhhh,
+lllll)
+require "code_format"
+```
+After formatting: 
+
+```lua
+print(aaa, bbbb, eeee, ffff,
+    ggggg, hhhhh,
+    lllll)
+require "code_format"
+```
+
+## Comment statements and inline comments
+
+Comment statements are divided into long comments and single-line short comments and inline comments
+* When the comment statement is formatted, the short comment will not make any changes, keeping the same line spacing as the next statement, while the large blank text of the long comment is considered part of the comment, so no changes will be made, and the same Same line spacing in the next statement
+* Inline comments, using the principle of keeping a space with the previous text, if the next element is still on the same line, it will also keep a space 
+
+```lua
+--[[
+    
+]]
+
+---@param f number
+---@return number
+function ffff(f)
+end
+
+local t = 123 --fffff
+local c = {
+    aaa = 123, --[[ffff]] dddd,
+    ccc = 456
+}
+```
+
+格式化后：
+
+```lua
+--[[
+    
+]]
+
+---@param f number
+---@return number
+function ffff(f)
+end
+
+local t = 123 --fffff
+local c = {
+    aaa = 123, --[[ffff]] dddd,
+    ccc = 456
+}
+```
+
diff --git a/docs/format_config_EN.md b/docs/format_config_EN.md
