Menu ▾ ▴

CONTRIBUTING

Michel Silva

Contributing

Ask not what Notepad++ can do for you - ask what you can do for Notepad++

Reporting Issues

Bug reports are appreciated. Following a few guidelines listed below will help speed up the process of getting them fixed.

  1. Search the issue tracker to see if it has already been reported.
  2. Disable your plugins to see if one of them is the problem. You can do this by renaming your plugins folder to something else.
  3. Only report an issue with a plugin if it is one of the standard plugins included in the Notepad++ installation. Any other plugin issue should be reported to its respective issue tracker (see e.g. plugin_list_x86.md or plugin_list_x64.md to find the homepage with further informations on that for a plugins). The standard plugins include (for v7.9.5):
    • NppExport
    • Converter
    • mimeTools
  4. Include additional information such as:
    • A detailed explanation
    • Notepad++ Debug-Info containing:
    • Operating System version
    • Notepad++ version
    • List of installed plugins (if it is related to a plugin)
    • Screen shots (if applicable)
    • ...and any other relevant information

Pull Requests

Your pull requests are welcome; however, they may not be accepted for various reasons. If you want to make some GUI enhancement like renaming some graphic items or fixing typos, please create the issue instead of the pull requests. All Pull Requests, except for translations and user documentation, need to be attached to a issue on GitHub. For Pull Requests regarding enhancements and questions, the issue must first be approved by one of project's administrators before being merged into the project. An approved issue will have the label Accepted. For issues that have not been accepted, you may request to be assigned to that issue.

Opening a 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 MUSIC-app++ coding style. Observe the code near your intended change, and attempt to preserve the style of that code with the changes you make.
  2. Create a new branch for each PR. Make sure your branch name wasn't used before - you can add date (for example patch3_20200528) to ensure its uniqueness.
  3. Single feature or bug-fix per PR.
  4. Create a PR with a single commit to make the review process easier.
  5. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
  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.

In short: The easier the code review is, the better the chance your pull request will get accepted.

GENERAL

  • Good:

    cpp if (){ // Do something }

  • Bad:
    ```cpp
if () 
{
    // Do something
}
```
  • Use tabs instead of white-spaces (we usually set our editors to 4 white-spaces for 1 tab, but the choice is up to you).
  • Always leave one space before and after binary and ternary operators.
  • Good:
    ```cpp
if (a == 10 && b == 42)
```
  • Bad:
    ```cpp
if (a==10&&b==42)
```
  • Only leave one space after semi-colons in "for" statements.
  • Good:
    ```cpp
for (int i = 0; i != 10; ++i)
```
  • Bad:
    ```cpp
for(int i=0;i<10;++i)
```
  • Function names are not separated from the first parenthesis.
  • Good:
    ```cpp
foo();
myObject.foo(24);
```
  • Bad:
    ```cpp
foo ();
```
  • Keywords are separated from the first parenthesis by one space.
  • Good:
    ```cpp
if (true)
while (true)
```
  • Bad:
    ```cpp
if(myCondition)
```
  • Use the following indenting for "switch" statements:

```cpp
switch (test) {
case 1:
// Do something
break;

  default:
      // Do something else

} // No semi-colon here
```

  1. Avoid magic numbers.
  2. Good:
    ```cpp
if (foo == I_CAN_PUSH_ON_THE_RED_BUTTON)
    startTheNuclearWar();
```
  3. Bad:
    ```cpp
while (lifeTheUniverseAndEverything != 42)
    lifeTheUniverseAndEverything = buildMorePowerfulComputerForTheAnswer();
```
  4. Prefer enums for integer constants.