Project

General

Profile

CodeReview Guideline » History » Version 1

jun chen, 03/09/2025 10:57 PM

1 1 jun chen
# CodeReview Guideline
2
3
## Guidelines before you push code review
4
1. use const as possible as you can, such as
5
6
> 1.pass built-in type by value
7
> 2.pass pointer(include smart pointer) by value
8
> 3.pass small object by value only if you know it is a small object such as LTPinld, else always passed by &
9
> 4.pass other types by const& if you will not change it.
10
> 5.member function should be marked as const if you do not change other members in this function
11
> 6.use const for return value only if the type is not a built-in type
12
13
14
2. use a meaningful variable/function name and do matched things
15
16
> 1.use verb + n for function name
17
> 2.use n + n ... for variable/class name
18
> 3.if the function name starts with is/has, it should be return a bool value
19
> 4.if the function name starts with get, it should be return a value
20
> 5.the function name should tell others what does the function do
21
22
23
**> # !!!!Do not use ambiguous name !!!!!**
24
25
3. avoid re-inventing the wheel
26
27
> 1.if some same codes were write more than once, we should use a function to do it.
28
> 2.use std container/algorithm as if as you can
29
> 3.use CM_ENUM_HELPER_DECLARE/CM_ENUM_HELPER_lMPL for any enum class
30
> 4.use NAMED_TUPLE instead of pair which could take more information such as each member name
31
> 5.unify those similar code with template or design pattern
32
33
34
4. write readable code with clear logic
35
36
> 1.idealy each function should not beyond one page of your editor
37
> 2.a huge function is very hard to understand for reviewers, split it into many small functions with a serials meaningful function name is better
38
> 3.if it is still hardly to understand, plz add essential comments
39
40
41
5. avoid to write meaningless code
42
43
> 1.check the invalid condition as earlier as you can in the begining of a function
44
> 2.just defined a variable when you really need it(idealy use it in the next line after the definition)
45
> 3.only export c++ functions to python when you really used it in the python
46
> 4.only do abbreviation if the abbreviation is not unique !!! a clear long name is always better than a short confused name !!
47
48
49
6. unify the coding style in a single file
50
51
> 1.use the same blank space surround the operator
52
> 2.use the same name style for variable and function
53
> 3.do not use number in any variable/function !!!
54
> 4.always use float instead of double, which is enough for 99% case
55
56
57
7. All partition based/chunk based structure should provide merge function and export to python, merge function must return the reference of itself!!!
58
59
8. Always use forward declaration instead of include headers, template class is the only exception
60
61
9. Do not merge data one by one, must use merge_data_in_paralle !!!
62
63
10. Always add noexcept for those class constructor to avoid huge core dump file