moonbitlang / moon

The build system and package manager for MoonBit
https://moonbitlang.github.io/moon/
GNU Affero General Public License v3.0
188 stars 17 forks source link

disable fmt block style by default #481

Closed Young-Flash closed 1 week ago

Young-Flash commented 1 week ago

cc https://github.com/moonbitlang/moon/pull/478

peter-jerry-ye-code-review[bot] commented 1 week ago

From the git diff output provided, here are three observations that could potentially be issues or areas for improvement in the MoonBit codebase:

  1. Redundant Doc Comments:

    • Several files (hello.mbt, main.mbt, etc.) have doc comments (///|) that are removed in the updated version. Doc comments are useful for documentation, but if they are empty or don't provide any meaningful information, they can be considered redundant. It's good practice to ensure that every doc comment adds value to the code's understanding.
    • Suggestion: Review and update doc comments to ensure they are informative and necessary. If a comment doesn't add any documentation value, consider removing it to keep the code clean.
  2. Inconsistent CLI Argument Handling:

    • The moonfmt command-line tool seems to handle extra arguments inconsistently. In some cases, the -block-style argument is removed, while in others, it remains. This could lead to confusion or errors if users expect consistent behavior across different command invocations.
    • Suggestion: Standardize the handling of extra arguments and ensure that the behavior is consistent across all related commands. If -block-style is no longer needed or relevant, remove it uniformly to avoid ambiguity.
  3. Unused Struct Field:

    • In the TestArtifacts struct within common.rs, there is a change related to the BlockStyle enum. Specifically, the False variant is moved to be the first variant. This could indicate that the False variant might not be used or is being reconsidered for its placement.
    • Suggestion: Verify the usage of the BlockStyle enum and its variants. Ensure that the order of variants does not impact functionality or readability. If a variant is no longer needed, consider removing it to simplify the code.

These observations focus on potential improvements in code clarity, documentation, and consistency, which are crucial for maintaining a high-quality codebase.