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 |