Use consistent coding style across all packages

[swift-kim]

This issue is for tracking the code refactoring status of this repo. The main goal is to improve

• Overall code quality
• Readability and maintainability
• Consistency

of all C++ code.

Here are some general rules for styling the code:

• Everything from the Google C++ Style Guide.
• Structure:
  • If the plugin class (which defines the RegisterWithRegistrar method) is too large (over 150 lines), consider breaking it into multiple classes.
    • The classes should have a clean design so that their roles can be easily known from their signatures. Ideally, the plugin class should be the only one that interacts with the underlying platform channel (processes method arguments and generates results), and other classes should not touch any Flutter API (flutter/*.h).
  • Enclose the plugin class within an anonymous namespace.
  • If you're writing a Tizen C API wrapper, avoid exposing Tizen-defined types (including enums) in its public interface.
  • Minimize use of output parameters when writing a function that returns a value. Consider using the GetLastError pattern (example) or defining your own result type such as TizenResult.
    • Consider making use of C++ exceptions if they make the code simpler and easier to understand (e.g. multiple platform API invocations per single method call). See this comment for other available options.
  • Consider creating an explicit stream handler class that extends flutter::StreamHandler if the plugin makes use of event channels. (example)
• Logging (log.h):
  • Avoid unnecessary logging. Minimize use of debug logs (LOG_DEBUG) in the final code.
  • Every log should provide useful information. Any information that is already known to the caller (through a PlatformException object) is redundant. Instead, provide some additional context about the error so that the developer can easily debug the underlying issue.
• Method call handling:
  • Consider using GetValueFromEncodableMap to extract arguments from an EncodableMap.
  • Prefer == over .compare() when comparing strings.

    const auto &method_name = method_call.method_name();
    
    if (method_name == "wifiName") {
      ...
    }

  • An error code (the first argument of result->Error()) should be either:
    • A return code (number converted to a string)
    • Invalid argument
    • Invalid operation
    • Operation failed/cancelled
    • Permission denied
    • Internal error
    • etc.
  • Do not skip the second argument (error message) of result->Error() whenever possible.
• Variable naming convention:
  • Use a local variable ret to store the return code of a Tizen API call.
  • Use a local variable self or plugin to store a pointer to the current class.
• Other recommendations:
  • Remove any unused includes (especially standard library headers).
  • Prefer if (value) over if (value != nullptr).
  • Consider inlining a C-style callback using a lambda expression if it makes the code cleaner.
  • Prefer fixed-width integer types (int32_t, int64_t) over plain old integer types (int, long long). This is not a strict requirement, and there are places where a plain int fits best. Also, you should avoid use of unsigned integer types.

I will start with 1st-party plugins and plus package implementations (there are already some PRs open). If you want to contribute to this project, you may start with 3rd-party plugins and Tizen-only plugins, or plugins authored by you if you have any.

Any comments are welcome. Please let me know if anything in the above is unclear.

[bbrto21]

That's a great suggestion. I think you've organized the things that we have to do for clean code, it's very clear.
I will also try to contribute to this issue as often as possible.