Our code formatting is enforced via CI.

Deskflow is reuse compliant and requires reuse lint to pass in order to build New files Must include license info. Either in a comment at the top of the file or in the REUSE.toml file

Examples:

/*
 * Deskflow -- mouse and keyboard sharing utility
 * SPDX-FileCopyrightText: (C) xxxx Deskflow Developers
 * SPDX-License-Identifier: GPL-2.0-only WITH LicenseRef-OpenSSL-Exception
 */

/*
 * Deskflow -- mouse and keyboard sharing utility
 * SPDX-FileCopyrightText: (C) xxxx - xxxx MY name <myemail>
 * SPDX-License-Identifier: GPL-2.0-only WITH LicenseRef-OpenSSL-Exception
 */

/*
 * Deskflow -- mouse and keyboard sharing utility
 * SPDX-FileCopyrightText: (C) xxxx - xxxx Deskflow Developers
 * SPDX-License-Identifier: GPL-2.0-only WITH LicenseRef-OpenSSL-Exception
 */

more info: https://spdx.dev/learn/handling-license-info/

1. Function names should be camelCase (for both class member functions and free functions)
2. Namespaces should be all lower case and begin with deskflow, e.g. deskflow::gui
3. Member variables should be prefixed with m_helloWorld
4. Static variables should be prefixed with s_, e.g. s_helloWorld
5. Pointers should begin with a lower case p, e.g. m_pHelloWorld
6. Getters should not have get prefixed, e.g. helloWorld()
7. Setters should have set prefixed, e.g. setHelloWorld(...)
8. Enum values and constants should be pascal case, e.g. HelloWorld (formerly enums began with k)
9. Class filenames should be pascal case, e.g. HelloWorld.cpp
10. Files with many classes or functions should be snake case, e.g. hello_world.cpp
11. Unit test names should follow the function-input-output pattern, e.g. helloWorld_fooIn_barOut
12. The word "deps" should be used to mean "dependencies"

1. You must use Q_SIGNALS in place of signals
2. You must use Q_SLOTS in place of slots
3. You must use Q_EMIT in place of emit

1. Qt Controls SHALL NOT use a p to indicate they are a pointer.
2. Qt Controls SHALL be named <type><Description> (lblShortName) OR <type>_<lenghtyDescription> (lbl_longerNamesMayUseThisStyle)
3. Qt signals should indicate that something happened, e.g. nameChanged

1. Members of UI forms SHALL NOT use the m_ prefix (i.e lblError NOT m_lblError)
2. Don't use the autoconnection conventions (on_foo_bar) or onFooBar.
3. Ui Forms should always be in the namespace Ui
   1. Always use ui{std::make_unique<Ui::Type>()} make the ui instance
   2. The Ui Form SHALL be a private member of the class using
   3. The variable name SHALL be ui
4. Ui Forms should never have connections internally
5. When editing ui files take extra care to not accidentally change
   1. item sizes
   2. the current item on container based widgets.

• label QLabels that are a static label
• lbl QLabels you will be changing programmatically
• rb QRadioButton
• cb QCheckBoxe
• combo QComboBox
• btn Buttons (Tool or Push)
• action QAction
• Others name without the Q

1. .cpp files should be ordered:
   • Copyright
   • Headers
   • using
   • Constants
   • Free functions
   • Class members
2. Headers should be ordered in separate groups of:
   • Header file for the .cpp file
   • For Qt, the .ui file
   • Project header files
   • 3rd party lib and system headers
3. Getters should be grouped together
4. Setters should be grouped together
5. Getters and setters should not be paired

1. Use ctor dependency injection (e.g. std::function or a Deps struct)
2. A unit test body should follow the AAA (arrange-act-assert) pattern, e.g.:

   auto foo = "hello";
   auto bar = "world";
   
   auto baz = combine(foo, bar);
   
   EXPECT_EQ(baz, "hello world");
   

3. A unit test should test only one scenario and expectation
   • Split test scenarios into separate test functions

1. Do not allow exceptions to propagate to Qt (instead, use qFatal())
   • Remember: qFatal on Windows for debug builds, will instead report _CRT_ERROR to connect your debugger to the app
2. Do use exceptions for exceptional situations (things that should not happen)
3. Do not use exceptions for validation (e.g. if a user input value is unexpected)

1. Use DEBUG for debug messages that do not occur frequently.
2. Use DEBUG1 for debug for high-frequency messages.
3. Use DEBUG2 for debug messages that are very high frequency (e.g. events system).
4. Omit function names from log strings because (it's impractical to keep them consistent long-term).
5. Use lower case for our log lines, instead of sentence case.
6. End log messages with numeric data if possible.
7. Wrap inserted strings with single quotes.
8. Do not end log messages with a period character.
9. A comma can be used to make the log line read easier.