notepad-plus-plus/CONTRIBUTING.md

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 information 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 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.
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.
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.

Coding style

GENERAL

1. Do not use Java-like braces

   • Good:

   void MyClass::method1()
   {
       if (aCondition)
       {
           // Do something
       }
   }
   

   • Bad:

   void MyClass::method1() {
       if (aCondition) {
           // Do something
       }
   }
   

   However, the method definition could be defined in a header file (.h), if there's one line code only. In this case, Java-like braces should be used.

   • Good:

   class MyClass
   {
   public:
       void method1();
       int method2() {
           return _x; // only one line code can be placed in .h as method definition
       };
   
   private:
       int _x;
   }
   

2. 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)

3. Always leave one space before and after binary and ternary operators

   • Good:

   if (a == 10 && b == 42)
   

   • Bad:

   if (a==10&&b==42)
   

4. Only leave one space after semi-colons in "for" statements

   • Good:

   for (int i = 0; i != 10; ++i)
   

   • Bad:

   for(int i=0;i<10;++i)
   

5. Function names are not separated from the first parenthesis

   • Good:

   foo();
   myObject.foo(24);
   

   • Bad:

   foo ();
   

6. Keywords are separated from the first parenthesis by one space

   • Good:

   if (true)
   while (true)
   

   • Bad:

   if(myCondition)
   

7. Switch

   • Use the following indenting for "switch" statements:

   switch (test)
   {
       case 1:
       {
           // Do something
           break;
       }
       default:
           // Do something else
   } // No semi-colon here
   

   • If possible use default statement, and prefer using it as last case.
   • When using switch with enum or known range, try to cover all values if not using default.

   enum class Test {val1, val2, val3}
   
   switch (Test)
   {
       case Test::val1:
       {
           // Do something
           break;
       }
   
       //case Test::val2:
       //case Test::val3:
       default: 
           // Do something else
   } // No semi-colon here
   

   When using default adding uncovered values as comments can help to convey intention.

   • Use [[fallthrough]] if fall through is intended.

   switch (test)
   {
       case 1:
       {
           // Do something
       }
       // I want fall through // adding comment can help to convey intention
       [[fallthrough]];
   
       case 2:
       {
           // Do something
           break;
       }
   
       default:
           // Do something else
   } // No semi-colon here
   

8. Avoid magic numbers

   • Good:

   if (foo == I_CAN_PUSH_ON_THE_RED_BUTTON)
       startTheNuclearWar();
   

   • Bad:

   while (lifeTheUniverseAndEverything != 42)
       lifeTheUniverseAndEverything = buildMorePowerfulComputerForTheAnswer();
   

9. Prefer enums for integer constants

10. Use initialization with curly braces

    • Good:

    MyClass instance{10.4};
    

    • Bad:

    MyClass instance(10.4);
    

11. Always use empty() for testing if a string is empty or not

    • Good:

    if (!string.empty())
    ...
    

    • Bad:

    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.

    • Good:

    char aChar = static_cast<char>(_pEditView->execute(SCI_GETCHARAT, j));
    

    • Bad:

    char aChar = (char)_pEditView->execute(SCI_GETCHARAT, j);
    

13. Use ! instead of not, && instead of and, || instead of or

    • Good:

    if (!::PathFileExists(dir2Search))
    

    • Bad:

    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.

    constexpr float g_globalVariable = 0.0F;
    
    void test()
    {
      constexpr UINT strLen = 1024U;
      wchar_t myString[strLen]{};
    }
    

NAMING CONVENTIONS

1. Classes uses Pascal Case

   • Good:

   class IAmAClass
   {};
   

   • Bad:

   class iAmAClass
   {};
   class I_am_a_class
   {};
   

2. Methods & method parameters

   • Use camel Case

   void myMethod(uint myVeryLongParameter);
   

3. Member variables

   • Any member variable name of class/struct should be preceded by an underscore.

   public:
       int _publicAttribute;
   private:
       int _pPrivateAttribute;
       float _pAccount;
   

4. Always prefer a variable name that describes what the variable is used for

   • Good:

   if (hours < 24 && minutes < 60 && seconds < 60)
   

   • Bad:

   if (a < 24 && b < 60 && c < 60)
   

COMMENTS

1. Use C++ comment line style rather than C comment style

   • Good:

   // Two lines comment
   // Use still C++ comment line style
   

   • Bad:

   /*
   Please don't piss me off with that
   */
   

BEST PRACTICES

1. Use C++11/14/17/20 whenever it is possible.

2. Use C++11 member initialization feature whenever it is possible.

   class Foo
   {
       int value = 0;
   };
   

3. Incrementing

   • Prefer Pre-increment

   ++i
   

   • Over Post-increment

   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.

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.

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

    // in StaticDialog.h
    isCheckedOrNot();
    setChecked();
    
    // 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:

    if (iAmYourFather == true)
    ...
    

    • Bad:

    if (true == iAmYourFather)
    ...
    

13. Check C++ Core Guidlines for additional guidelines.