Add some stuff to CONTRIBUTING.md

This commit is contained in:
miruka 2021-01-04 09:27:44 -04:00
parent aaf0eb2f09
commit fe9d26eaf8

View File

@ -126,27 +126,25 @@ implementation or side-effects.
- Use four space indentations, no tabs - Use four space indentations, no tabs
- Use double quotes for strings, unless single quotes would avoid having to - Use double quotes for strings, unless single quotes would avoid having to
escape quotes in the text escape double quotes in the text
- Keep lines under 80 columns, the only exception for this is long URL links - Keep lines under 80 columns, the only exception for this is long URL links
that can't be broken in multiple parts that can't be broken in multiple parts
- Keep lines free from any trailing whitespace - Keep lines free from any trailing whitespace
- For function definitions, calls and list/dict/etc not fitting in - Function definitions, calls, list/dict/etc not fitting in
one line, keep a trailing comma on the last element: one line follow this format (notice the trailing comma on the last element):
```python3 ```python3
short_function(1, 2, 3) long_function_call(
long_argument_1, long_argument_1, long_argument_3, long_argument_4,
long_function(
long_argument_1, long_argument_1, long_argument_3, long_argument_4, # 🡐
) )
large_list = [ very_long_list_def = [
"some long piece of text here number 1", "Lorem ipsum dolor sit amet, consectetuer adipiscing elit",
"some long piece of text here number 2", "Aenean massa. Cum sociis natoque penatibus",
"some long piece of text here number 3", # 🡐 "Mus donec quam felis, ultricies nec, pellentesque",
] ]
``` ```
@ -161,13 +159,13 @@ implementation or side-effects.
For classes with many long methods, separate those methodes by two blank For classes with many long methods, separate those methodes by two blank
lines too. lines too.
- Readability is important. Vertically align consecutive lines of assignments, - Readability is important. Vertically-align consecutive lines of assignments,
function definition arguments, dictionaries and inline comments: function definition arguments, dictionaries and inline comments:
```python3 ```python3
# Bad: # Bad:
num: int = 1 # A comment num: int = 1 # A comment
args: List[str] = ["a", "b"] # Another comment args: List[str] = ["a", "b"] # Another comment
def func( def func(
@ -175,8 +173,6 @@ implementation or side-effects.
example_argument: int = 300, # Comment example_argument: int = 300, # Comment
other: str = "Sample text", # Other comment other: str = "Sample text", # Other comment
some_floats: Tuple[float, float, float] = (4.2, 1.1, 9.8), some_floats: Tuple[float, float, float] = (4.2, 1.1, 9.8),
xyz: bool = False,
things_set: Optional[Set[str]] = None,
) -> None: ) -> None:
pass pass
@ -190,8 +186,6 @@ implementation or side-effects.
example_arg: int = 300, # Comment example_arg: int = 300, # Comment
other: str = "Sample text", # Other comment other: str = "Sample text", # Other comment
some_floats: Tuple[float, float] = (4.2, 9.8), some_floats: Tuple[float, float] = (4.2, 9.8),
xyz: bool = False,
things_set: Optional[Set[str]] = None,
) -> None: ) -> None:
pass pass
``` ```
@ -224,8 +218,14 @@ implementation or side-effects.
} }
``` ```
- Don't use [States](https://doc.qt.io/qt-5/qml-qtquick-state.html). - When creating new files, the `id` for the root component should always
The Rectangle in the description's example could simply be written like this: be `root`
- When writing new code, refer to parent object properties explicitely, e.g.
`parent.prop_name` or `someId.prop_name` instead of just `<prop_name>`
- Don't use [States](https://doc.qt.io/qt-5/qml-qtquick-state.html),
the Rectangle in the description's example could simply be written like this:
```qml ```qml
Rectangle { Rectangle {
@ -251,12 +251,11 @@ implementation or side-effects.
exposed with some wrapper code exposed with some wrapper code
([example](https://github.com/mirukana/mirage/blob/v0.6.4/src/utils.h#L31)). ([example](https://github.com/mirukana/mirage/blob/v0.6.4/src/utils.h#L31)).
- Always use `this->` to refer to methods and class attributes, explicit is - Be explicit, always use `this->` to refer to methods and class attributes
better than implicit
- Don't split modules between `.h` and `.cpp` files, this creates unnecessary - Don't split modules between `.h` and `.cpp` files, this creates unnecessary
code repetition and is detrimental to performance when most functions will code repetition and has no benefits when most methods will
contain very few lines and will only get included once before contain very few lines and the module is only included once before
starting the GUI. starting the GUI.