@ -27,8 +27,6 @@ Your pull requests are welcome; however, they may not be accepted for various re
Opening an issue beforehand allows the administrators and the community to discuss bugs and enhancements before work begins, preventing wasted effort.
### Guidelines for pull requests
1. Respect existing Notepad++ coding style. Observe the code near your intended change, and attempt to preserve the style of that code with the changes you make.
@ -39,22 +37,22 @@ Opening an issue beforehand allows the administrators and the community to discu
6. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
7. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
8. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
9. Finally, please test your pull requests, at least once.
9. When creating new PR, try to base it on latest master.
10. Don't merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
11. Finally, please test your pull requests, at least once.
In short: The easier the code review is, the better the chance your pull request will get accepted.
11. ##### Always use `empty()` for testing if a string is empty or not.
11. Always use `empty()` for testing if a string is empty or not
* Good:
* ###### Good:
```cpp
if (!string.empty())
...
```
* ###### Bad:
* Bad:
```cpp
if (string != "")
...
```
12. Always use `C++ conversion` instead of `C-Style cast`
* Generally, all the conversion among types should be avoided. If you have no choice, use C++ conversion.
12. ##### Always use `C++ conversion` instead of `C-Style cast`. Generally, all the conversion among types should be avoided. If you have no choice, use C++ conversion.
13. ##### Use `!` instead of `not`, `&&` instead of `and`, `||` instead of `or`.
13. Use `!` instead of `not`, `&&` instead of `and`, `||` instead of `or`
* Good:
* ###### Good:
```cpp
if (!::PathFileExists(dir2Search))
```
* ###### Bad:
* Bad:
```cpp
if (not ::PathFileExists(dir2Search))
```
14. Always initializatize local and global variables
* For primitive types and enum prefer initialization with `=`.
* For other prefer `{}`-initializer syntax.
* For "numerical" variables using literal suffix can help to convey intention.
```cpp
constexpr float g_globalVariable = 0.0F;
void test()
{
constexpr UINT strLen = 1024U;
wchar_t myString[strLen]{};
}
```
#### NAMING CONVENTIONS
1. ##### Classes uses Pascal Case
1. Classes uses Pascal Case
* Good:
* ###### Good:
```cpp
class IAmAClass
{};
```
* ###### Bad:
* Bad:
```cpp
class iAmAClass
{};
@ -241,15 +328,17 @@ In short: The easier the code review is, the better the chance your pull request
{};
```
2. ##### Methods & method parameters use camel Case
2. Methods & method parameters
* Use camel Case
```cpp
void myMethod(uint myVeryLongParameter);
```
3. ##### Member variables
3. Member variables
Any member variable name of class/struct should be preceded by an underscore.
* Any member variable name of class/struct should be preceded by an underscore.
```cpp
public:
@ -259,44 +348,44 @@ Any member variable name of class/struct should be preceded by an underscore.
float _pAccount;
```
4. ##### Always prefer a variable name that describes what the variable is used for.
4. Always prefer a variable name that describes what the variable is used for
* Good:
* ###### Good:
```cpp
if (hours <24&&minutes<60&&seconds<60)
```
* ###### Bad:
* Bad:
```cpp
if (a <24&&b<60&&c<60)
```
#### COMMENTS
1. ##### Use C++ comment line style rather than C comment style.
1. Use C++ comment line style rather than C comment style
* ###### Good:
```
* Good:
```cpp
// Two lines comment
// Use still C++ comment line style
```
* ###### Bad:
```
* Bad:
```cpp
/*
Please don't piss me off with that
*/
```
#### BEST PRACTICES
1. ##### Use C++11/14/17 whenever it is possible
1. Use C++11/14/17/20 whenever it is possible.
2. ##### Use C++11 member initialization feature whenever it is possible
2. Use C++11 member initialization feature whenever it is possible.
```cpp
class Foo
@ -305,23 +394,62 @@ Any member variable name of class/struct should be preceded by an underscore.
};
```
3. ##### Prefer Pre-increment:
3. Incrementing
* Prefer Pre-increment
```cpp
++i
```
##### **Over Post-increment:**
* Over Post-increment
```cpp
i++
```
(It does not change anything for built-in types but it would bring consistency)
4. ##### Avoid using pointers. References are preferred instead. You might need the variable to be assigned a NULL value: in this case the NULL value has semantics and must be checked. Wherever possible, use a SmartPtr instead of old-school pointers.
4. Avoid using pointers. References are preferred instead. You might need the variable to be assigned a `NULL` value: in this case the `NULL` value has semantics and must be checked. Wherever possible, use a SmartPtr instead of old-school pointers.
5. ##### Avoid using new if you can use automatic variable. However, avoid `shared_ptr` as much as possible. Prefer `unique_ptr` instead.
5. Avoid using new if you can use automatic variable. However, avoid `shared_ptr` as much as possible. Prefer `unique_ptr` instead.
6. ##### Don't place any "using namespace" directives in headers.
6. Don't place any "using namespace" directives in headers.
7. Compile time is without incidence. Increasing compile time to reduce execution time is encouraged.
8. Code legibility and length is less important than easy and fast end-user experience.
9. Prefer `constexpr` over `const` if value can be evaluated at compile time.
10. Check if there are helper functions in headers or lambda fuctions to reuse them instead of writing new code.
* Example
```cpp
// in StaticDialog.h
isCheckedOrNot();
setChecked();
7. ##### Compile time is without incidence. Increasing compile time to reduce execution time is encouraged.
// in Parameters.cpp
parseYesNoBoolAttribute();
```
11. Check if there is already defined global variable, and reuse it instead of defining new one.
12. Avoid "Yoda conditions".
* Good:
```cpp
if (iAmYourFather == true)
...
```
* Bad:
```cpp
if (true == iAmYourFather)
...
```
8. ##### Code legibility and length is less important than easy and fast end-user experience.
13. Check [C++ Core Guidlines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md) for additional guidelines.