Best Practices: Trim trailing whitespace

Author: kadet1090

bestpractices/c++practices.md

@@ -4,7 +4,7 @@ layout: default
 
 # C++ practices
 
-Most rules presented here cover the same things as the very good [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines). 
+Most rules presented here cover the same things as the very good [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines).
 Whenever something is not covered or you are in doubt - don't hesitate to consult it - it is a very good source of information.
 
 ## Avoid anonymous namespaces
@@ -31,7 +31,7 @@ In addition, private static functions doesn't even need to be declared in the he
 
 Data is information, facts etc. An algorithm is code that operates on data.
 
-Programming languages, or their libraries, include thoroughly tested algorithms to handle common data structures. 
+Programming languages, or their libraries, include thoroughly tested algorithms to handle common data structures.
 
 By properly considering algorithms and data structure, and keeping data separate from code, both code and data become simpler, more reliable, more flexible, and easier to maintain for the next person.
 
@@ -106,7 +106,7 @@ static constexpr std::array<PrefixSpec, 7> sortedPrefixes {
 	{'M', 1ULL << 20},  // 1 << 20 = 2^20 = 1024
 	{'k', 1ULL << 10},  // 1 << 10 = 2^10 = 1024
 	{'\0', 0}}};
-    
+
 const auto res = std::find_if(prefixes.begin(), prefixes.end(), [&](const auto& spec) {
 	return spec.factor <= size;
 });
@@ -212,7 +212,7 @@ A function which has hard dependencies cannot function, be understood, edited or
 
 Code and its dependencies are said to be _coupled._ When different pieces of code _have the same_ dependency, they in turn are coupled to each other.
 
-Required information can be injected via constructor or method parameters. 
+Required information can be injected via constructor or method parameters.
 
 If it is necessary to introduce external code (e.g. a service object), do so by passing an interface, helper function or similar to avoid coupling.
 
@@ -393,7 +393,7 @@ when removing repetition.
 Whilst lambdas are quite happy with simple auto parameters, best not
 to omit const or & as appropriate. Types may be required to help the IDE.
 
-Consider the following code: 
+Consider the following code:
 ```c++
 doSomething()
 if (somethingWentWrong()) {
@@ -605,4 +605,4 @@ constexpr std::array<Button, numButtons> buttonDefs {{
 }};
 ```
 
-When in doubt, use a struct - it is better to have good names than not.
+When in doubt, use a struct - it is better to have good names than not.

bestpractices/codereview.md

@@ -11,10 +11,10 @@ You can always consult it to learn more useful stuff.
 
 While points of this guide might not be consistently followed throughout all of the existing codebase, checking if new code follows them is possible and in long term should help us immensely.
 
-> [!NOTE]  
+> [!NOTE]
 > Remember that code review is a collaborative discussion. Don’t hesitate to ask for clarification or help when needed. Reviewers can also make mistakes, the goal is to work together to refine the code to a point where everyone is satisfied.
 
-In this document the **bolded** text will indicate how important each suggestion is. 
+In this document the **bolded** text will indicate how important each suggestion is.
  - **must** will be used for fundamental things that should be non-controversial and which you really should follow
  - **should** will be used for important details that will apply for vast majority of cases, there could however be valid reasons to ignore them depending on context
  - **could** will be used for best practices, things that you should try to follow but not following them is not an error per se
@@ -38,11 +38,11 @@ In this document the **bolded** text will indicate how important each suggestion
 4. Early-Exit **should** be preferred to prune unwanted execution branches fast.
 7. Global state (global variables, static fields, singletons) **should be** avoided.
 8. (C++ only) `enum class` **should** be preferred over normal enum whenever possible.
-9. (C++ only) C++ libraries/structures **should** be preferred over C ones. i.e. `std::array/vector` should be used instead of C array. 
+9. (C++ only) C++ libraries/structures **should** be preferred over C ones. i.e. `std::array/vector` should be used instead of C array.
 10. (C++ only) C++ standard library **should** be utilized if possible, especially the `<algorithms>` one.
     <details>
         <summary>Example #1</summary>
-        
+
         Consider following code:
         ```c++
             std::vector<int> vertices;
@@ -87,7 +87,7 @@ In this document the **bolded** text will indicate how important each suggestion
 14. All members **must** be initialized.
     <details>
         <summary>Rationale</summary>
-        Not initialized members can easily cause undefined behaviors that are really hard to find. 
+        Not initialized members can easily cause undefined behaviors that are really hard to find.
     </details>
 
 ## Design / Architecture
@@ -105,7 +105,7 @@ In this document the **bolded** text will indicate how important each suggestion
 5. Long methods **should** be split into smaller, better described ones.
 6. (C++ only) Defining new macros **must** be avoided, unless absolutely necessary.
 7. Integers **must not** be used to express anything other than numbers. For enumerations enums **must** be used.
-8. Code **should** be written in a way that it expresses intent, i.e. what should be done, rather than just how it is done. 
+8. Code **should** be written in a way that it expresses intent, i.e. what should be done, rather than just how it is done.
     <details>
         <summary>Example #1</summary>
         Consider this code:
@@ -115,7 +115,7 @@ In this document the **bolded** text will indicate how important each suggestion
                 // ... some code ...
 
                 QDockWidget *dock = nullptr;
-                
+
                 for (auto w = qApp->widgetAt(QCursor::pos()); w; w = w->parentWidget()) {
                     dock = qobject_cast<QDockWidget*>(w);
                     if (dock) {
@@ -144,10 +144,10 @@ In this document the **bolded** text will indicate how important each suggestion
                 toggleOverlay(dock, m);
             }
         ```
-        
-        It is hard to understand what is the job of the for loop inside `if (!dock)` statement. 
+
+        It is hard to understand what is the job of the for loop inside `if (!dock)` statement.
         We can refactor it to a new `QWidget* findClosestDockWidget()` method for it to look like this:
-        
+
         ```c++
             void setOverlayMode(OverlayMode mode)
             {
@@ -168,27 +168,27 @@ In this document the **bolded** text will indicate how important each suggestion
 
         That way reading through code of `setOverlayMode` we don't need to care about the details of finding the closest dock widget.
     </details>
-10. Boolean arguments **must** be avoided. Use enumerations instead - enum with 2 values is absolutely fine. 
+10. Boolean arguments **must** be avoided. Use enumerations instead - enum with 2 values is absolutely fine.
     For python boolean arguments are ok, but they **must** forced to be keyword ones.
     <details>
         <summary>example #1 (c++)</summary>
         consider following example:
-        
+
         ```c++
         mapper.populate(false, it.key(), it.value());
         ```
 
         it is impossible to understand what false means without consulting the documentation or at least the method signature.
         instead the enum should be used:
-        
+
         ```c++
         mapper.populate(mappingstatus::modified, it.key(), it.value());
         ```
 
         now the intent is clear
     </details>
 11. (C++ only) Code **should** prefer uniform initialization `{ }` (also called brace initialization). Prevents narrowing.
-12. (C++ only) Class member variables **should** be initialized at declaration, not in constructors 
+12. (C++ only) Class member variables **should** be initialized at declaration, not in constructors
 13. Magic numbers or other literals **must** be avoided.
 
 

bestpractices/index.md

@@ -5,10 +5,10 @@ layout: default
 # Best Practices
 
 Although this chapter is not FreeCAD specific, it is provided here to help both developers and code reviewers to ensure
-clean and easily maintainable code. The practices presented should be treated like food recipes - you can play with them, 
+clean and easily maintainable code. The practices presented should be treated like food recipes - you can play with them,
 alter them - but every change should be thoughtful and intentional.
 
-While this guideline might not be consistently followed throughout all of the existing codebase, adhering to these practices 
+While this guideline might not be consistently followed throughout all of the existing codebase, adhering to these practices
 moving forward will help improve the overall quality of the code and make future contributions more maintainable. Consider it
 as inspiration for the better future.
 

bestpractices/pythonpractices.md

@@ -1,3 +1,3 @@
 # Python Practices
 
-Work in Progress - looking for help!
+Work in Progress - looking for help!