mirror-chatterino2/CONTRIBUTING.md

218 lines
8.1 KiB
Markdown
Raw Normal View History

2019-10-13 11:15:09 +02:00
# Chatterino code guidelines
2019-10-29 21:09:42 +01:00
This is a set of guidelines for contributing to Chatterino. The goal is to teach programmers without C++ background (java/python/etc.), people who haven't used Qt or otherwise have different experience the idioms of the codebase. Thus we will focus on those which are different from those other environments. There are extra guidelines available [here](https://hackmd.io/@fourtf/chatterino-pendantic-guidelines) but they are considered as extras and not as important.
2019-10-13 11:15:09 +02:00
# Tooling
2021-02-21 14:45:42 +01:00
## Formatting
2019-10-13 11:15:09 +02:00
2019-10-29 21:09:42 +01:00
Code is automatically formatted using `clang-format`. It takes the burden off of the programmer and ensures that all contributors use the same style (even if mess something up accidentally). We recommend that you set up automatic formatting on file save in your editor.
2019-10-13 11:15:09 +02:00
# Comments
Comments should only be used to:
2019-10-13 13:30:45 +02:00
- Increase readability (e.g. grouping member variables).
- Containing information that can't be expressed in code.
Try to structure your code so that comments are not required.
#### Good example
2021-02-21 14:45:42 +01:00
```cpp
/// Result is 0 if a == b, negative if a < b and positive if b > a.
/// ^^^ You can't know this from the function signature!
// Even better: Return a "strong ordering" type.
// (but we don't have such a type right now)
int compare(const QString &a, const QString &b);
```
#### Bad example
2021-02-21 14:45:42 +01:00
```cpp
/*
* Matches a link and returns boost::none if it failed and a
2021-02-21 14:45:42 +01:00
* QRegularExpressionMatch on success.
* ^^^ This comment just repeats the function signature!!!
2021-02-21 14:45:42 +01:00
*
* @param text The text that will be checked if it contains a
* link
* ^^^ No need to repeat the obvious.
*/
boost::optional<QRegularExpressionMatch> matchLink(const QString &text);
```
2019-10-13 11:15:09 +02:00
# Code
2021-02-21 14:45:42 +01:00
## Arithmetic Types
2019-10-13 11:15:09 +02:00
2019-10-29 21:09:42 +01:00
Arithmetic types (like char, short, int, long, float and double), bool, and pointers are NOT initialized by default in c++. They keep whatever value is already at their position in the memory. This makes debugging harder and is unpredictable, so we initialize them to zero by using `{}` after their name when declaring them.
2019-10-13 11:15:09 +02:00
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
class ArithmeticTypes
{
int thisIs0{};
QWidget *thisIsNull{};
bool thisIsFalse_{};
// int a; // <- Initialized to "random" value.
// QWidget *randomPtr.
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
std::vector<int> myVec; // <- other types call constructors instead, so no need for {}
// std::vector<int> myVec{}; <- pointless {}
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
int thisIs5 = 5; // <- Also fine, we initialize it with another value.
};
void myFunc() {
int a = 1 + 1; // <- here we initialize it immediately, so it's fine.
}
```
2021-02-21 14:45:42 +01:00
## Passing parameters
2019-10-29 21:09:42 +01:00
The way a parameter is passed signals how it is going to be used inside of the function. C++ doesn't have multiple return values so there is "out parameters" (reference to a variable that is going to be assigned inside of the function) to simulate multiple return values.
2019-10-13 11:15:09 +02:00
**Cheap to copy types** like int/enum/etc. can be passed in per value since copying them is fast.
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
void setValue(int value) {
// ...
}
```
**References** mean that the variable doesn't need to be copied when it is passed to a function.
2019-10-13 11:28:19 +02:00
2021-02-21 14:45:42 +01:00
| type | meaning |
| ------------------ | ---------------------------------------------------------------------------------------- |
| `const Type& name` | _in_ Parameter. It is NOT going to be modified and may be copied inside of the function. |
| `Type& name` | _out_ or _in+out_ Parmameter. It will be modified. |
2019-10-13 11:15:09 +02:00
**Pointers** signal that objects are managed manually. While the above are only guaranteed to live as long as the function call (= don't store and use later) these may have more complex lifetimes.
2021-02-21 14:45:42 +01:00
| type | meaning |
| ------------ | -------------------------------------------------------------------------------------------------------------------------- |
| `Type* name` | The lifetime of the parameter may exceed the length of the function call. It may use the `QObject` parent/children system. |
2019-10-13 11:15:09 +02:00
**R-value references** `&&` work similar to regular references but signal the parameter should be "consumed".
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
void storeLargeObject(LargeObject &&object) {
// ...
}
void storeObject(std::unique_ptr<Object> &&object) {
// ...
}
void main() {
// initialize a large object (= will be expensive to copy)
LargeObject large = // ...
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
// Object accepts an r-value reference + we use std::move()
// => We move the object = no need to copy.
storeLargeObject(std::move(large));
// But even worse, you can't copy a unique_ptr so we need to move here!
std::unique_ptr<Object> unique = // ...
storeObject(std::move(unique));
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
// The pointer contained by unique has now been consumed by "storeObject"
// so it just holds a null pointer now.
assert(unique.get() == nullptr);
}
```
Generally the lowest level of requirement should be used e.g. passing `Channel&` instead of `std::shared_ptr<Channel>&` (aka `ChannelPtr`) if possible.
2021-02-21 14:45:42 +01:00
## Members
2019-10-13 11:15:09 +02:00
2021-02-21 14:45:42 +01:00
All functions names are in `camelCase`. _Private_ member variables are in `camelCase_` (note the underscore at the end). We don't use the `get` prefix for getters. We mark functions as `const` [if applicable](https://stackoverflow.com/questions/751681/meaning-of-const-last-in-a-function-declaration-of-a-class).
2019-10-13 11:15:09 +02:00
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
class NamedObject
{
public:
const QString &name() const; // <- no "get" prefix.
void setName(const QString &name);
bool hasLongName() const; // <- "has" or "is" prefix is okay
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
static void myStaticFunction(); // <- also lowercase
QString publicName;
private:
// Private variables have "_" suffix.
QString name_;
// QString name; <- collides with name() function
};
void myFreeStandingFunction(); // <- also lower case
```
2021-02-21 14:45:42 +01:00
## Casts
2019-10-13 11:15:09 +02:00
- **Avoid** c-style casts: `(type)variable`.
- Instead use explicit type casts: `type(variable)`
2021-02-21 14:45:42 +01:00
- Or use one of [static_cast](https://en.cppreference.com/w/cpp/language/static_cast), [const_cast](https://en.cppreference.com/w/cpp/language/const_cast) and [dynamic_cast](https://en.cppreference.com/w/cpp/language/dynamic_cast)
2019-10-13 11:15:09 +02:00
- Try to avoid [reinterpret_cast](https://en.cppreference.com/w/cpp/language/reinterpret_cast) unless necessary.
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
void example() {
float f = 123.456;
int i = (int)f; // <- don't
int i = int(f); // <- do
Base* base = // ...
Derived* derived = (Derived*)base; // <- don't
Derived* derived = dynamic_cast<Derived*>(base); // <- do
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
// Only use "const_cast" solved if using proper const correctness doesn't work.
const int c = 123;
((int &)c) = 123; // <- don't
const_cast<int &>(c) = 123; // <- do (but only sometimes)
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
// "reinterpret_cast" is also only required in very rarely.
int p = 123;
float *pp = (float*)&p;
float *pp = reinterpret_cast<float*>(&p);
}
```
2021-02-21 14:45:42 +01:00
## This
2019-10-13 11:15:09 +02:00
Always use `this` to refer to instance members to make it clear where we use either locals or members.
2021-02-21 14:45:42 +01:00
```cpp
2019-10-13 11:15:09 +02:00
class Test
{
void testFunc(int a);
int testInt_{};
}
Test::testFunc(int a)
{
// do
this->testInt_ += 2;
this->testFunc();
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
// don't
testInt_ -= 123;
testFunc(2);
this->testFunc(testInt_ + 1);
}
```
2021-02-21 14:45:42 +01:00
## Managing resources
2019-10-13 11:15:09 +02:00
#### Regular classes
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
Keep the element on the stack if possible. If you need a pointer or have complex ownership you should use one of these classes:
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
- Use `std::unique_ptr` if the resource has a single owner.
- Use `std::shared_ptr` if the resource has multiple owners.
#### QObject classes
2021-02-21 14:45:42 +01:00
2019-10-13 11:15:09 +02:00
- Use the [object tree](https://doc.qt.io/qt-5/objecttrees.html#) to manage lifetime where possible. Objects are destroyed when their parent object is destroyed.
2019-10-18 18:54:58 +02:00
- If you have to explicitly delete an object use `variable->deleteLater()` instead of `delete variable`. This ensures that it will be deleted on the correct thread.
2019-10-13 11:15:09 +02:00
- If an object doesn't have a parent consider using `std::unique_ptr<Type, DeleteLater>` with `DeleteLater` from "src/common/Common.hpp". This will call `deleteLater()` on the pointer once it goes out of scope or the object is destroyed.