fix: [cppcheck] Improve code formatting for architecture mapping

[add-uos]

Enhanced readability of the architecture mapping table by reformatting the static QMap initialization with proper indentation and line breaks.

Log: Refactor architecture mapping code style
Change-Id: Iea19f9e13e7b8f59f66d34877e555994832a0221

Summary by Sourcery

Reformat static QMap initializations across source and header files to enhance readability and maintain a consistent code style.

Enhancements:

• Improve code formatting of static QMap initializations for architecture mapping and error string map
• Adjust indentation for consistent style in commonfunction.h, commonfunction.cpp, and commontools.h

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Reformatted static QMap initializations for architecture mapping and aligned declaration of error string map to improve code readability and maintain consistent styling.

Class diagram for updated QMap initializations

classDiagram
    class commonfunction {
        +static QMap<QString, QString> mapArch
    }
    class commontools {
        +static QMap<DriverType, QString> m_MapDriverType
        +static QMap<Status, QString> m_MapStatusIcon
        +static QMap<Status, QString> m_MapStatusType
        +static QMap<int, QString> m_MapErrorString
    }

Loading

File-Level Changes

Change	Details	Files
Refactored static QMap<QString, QString> initialization for architecture mapping	Moved opening brace to its own line Placed each key-value pair on a separate, indented line Unified comma placement before each subsequent entry	deepin-devicemanager-server/deepin-devicecontrol/src/drivercontrol/commonfunction.h deepin-devicemanager/src/commonfunction.cpp
Adjusted indentation of error string map declaration	Removed extra blank line before declaration Aligned whitespace before member name to match surrounding declarations	deepin-devicemanager/src/Tool/commontools.h

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[deepin-ci-robot]

deepin pr auto review

根据提供的git diff内容，我将从代码质量、语法逻辑、性能和安全性等方面进行分析并提出改进建议：

1. 代码格式和风格改进：

• 在commonfunction.h和commonfunction.cpp中，mapArch的初始化格式得到了改进，从单行改为多行格式，提高了可读性。建议继续保持这种格式。
• 在DBusAnythingInterface.h中，m_mutex和mp_Iface的缩进和格式得到了统一，提高了代码的一致性。

2. 注释完善：

• 在EDIDParser.h中，m_MapCh的注释得到了完善，说明了其用途是"二进制字符串映射到字母A-Z"。
• 在ThreadExecXrandr.h中，m_monitorLst的注释得到了完善，说明了其用途是"DBus中反馈的显示器列表"。
• 建议为其他成员变量也添加类似的注释，特别是那些功能不太明显的变量。

3. 变量命名：

• 在EDIDParser.h中，m_Heigth存在拼写错误，应该是m_Height。这是一个需要修复的bug。
• 建议检查整个代码库中是否有类似的拼写错误。

4. 代码结构：

• 在commontools.h中，m_MapErrorString的缩进得到了调整，与其他成员变量的格式保持一致。
• 建议确保整个项目中所有头文件的格式和缩进保持一致。

5. 性能考虑：

• mapArch是一个静态的QMap，在多个地方定义，可能会导致重复初始化。建议将其定义放在一个源文件中，并在头文件中声明为extern。
• 对于频繁访问的静态成员变量，如m_MapDriverType、m_MapStatusIcon等，可以考虑使用const引用来避免不必要的拷贝。

6. 安全性：

• 对于DBus接口的调用，建议添加错误处理机制，特别是在DBusAnythingInterface中。
• 对于从外部获取的数据（如EDID数据），建议进行有效性验证，防止解析时出现越界访问。

7. 其他建议：

• 考虑使用枚举类替代一些字符串映射，如DriverType和Status，可以提高类型安全性。
• 对于静态成员变量的初始化，建议在cpp文件中进行集中初始化，而不是分散在多个地方。

总的来说，这些修改主要是关于代码格式、注释和变量命名的改进，这些改动有助于提高代码的可读性和可维护性。同时，也发现了一些潜在的问题，如变量拼写错误和可能的性能问题，建议在后续开发中加以注意和改进。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: add-uos, max-lvs

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[add-uos]

/merge