Revisit development rules for more efficiency

[kenji-miyake]

We'll send PRs for each item and discuss them in the PRs.

• Change formatters to clang-format and Black
• Change C++ namespace rule to be the same as the package name
• Change the package rule not to split core/node packages
• Replace ade with pure Docker in the installation section -> docs: add installation steps #18
• Write coding guidelines for each language
  • Common(naming etc.)
  • C++
  • Python
  • Markdown
  • etc. (Images, Shell Scripts, GitHub Actions)
• Write coding guidelines for ROS node
• Update documentation guidelines
  • It's worth discussing whether we really need Doxygen comments for all header files. (In other words, what the public APIs of Autoware's packages are.)
• Update testing guidelines -> wip: update testing-in-general #39
• Update contribution guidelines
  • Workflow -> docs: add pull request guidelines #45
  • Commit rules docs: add commit guidelines #47
• Update how to write license notations -> fix typo autoware#29
• Update code of conduct to v2.1 -> fix typo autoware#29
• Update support guidelines to use GitHub Discuttions (proposing in Revisit user support/communication platform for more collaboration #7)

[isamu-takagi]

I think we need rules to clarify the interface for the following reasons.

• It's often difficult to know what parameters/topic the node has because the interface definitions (e.g. create_subscription) are scattered in the code.
• There is no way to know which topics are public or private in the launch file.
• A mixture of the default values in the source code and the remap values in the launch file.

[IshitaTakeshi]

Not a strict rule, but there's a guideline to write good code, called Object Calisthenics. This is a pretty strict guideline, so it is not necessary to precisely follow, but it helps to write testable, reusable, and extensible code.

[IshitaTakeshi]

Anyway, whatever we adopt, it would be better to have some tips or guidelines for writing good code other than coding rules.
By accumulating knowledge and tips and publishing them, we can improve our product quality and contribute to open source communities.

[kenji-miyake]

Not a strict rule, but there's a guideline to write good code, called Object Calisthenics. This is a pretty strict guideline, so it is not necessary to precisely follow, but it helps to write testable, reusable, and extensible code.

In that case, it's better to link the document as a reference.
Regarding some important techniques can be picked up and be written in our guidelines. (If there are no license issues.)

Anyway, whatever we adopt, it would be better to have some tips or guidelines for writing good code other than coding rules.

Yes, of course. I'm preparing it.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[kenji-miyake]

I think I can write some more documents this month.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.