Inconsistent Naming Conventions in code and API.yml

[andylizf]

There is an inconsistency in the naming conventions used within our codebase and the API.yml file. Specifically, some variable and attribute names are using snake_case, while others are using camelCase. This inconsistency might lead to confusion, reduce code readability, and potentially cause errors in future development.

For example, in page-respond.dto.ts,

export class PageRespondDto {
  @IsNumber()
  page_start: number;

  @IsNumber()
  page_size: number;

  @IsNumber()
  has_prev: boolean;

  @IsNumber()
  prev_start: number;

  @IsNumber()
  has_more: boolean;

  @IsNumber()
  next_start: number;
}

and camelStyle is used elsewhere.

In addition, this mismatch also occurs between API.yml and the codebase.

[Nictheboy]

Using snake_case in DTO classes is due to the fact that the field names in a DTO class is the field names in the JSON response.

If we want to change naming conventions in DTO classes, then API.yml and front-end code should be changed, too, together with all the test cases.

I think this is not a high priority issue.

[Nictheboy]

From API.yml:

    Page:
      type: object
      description: 分页信息
      properties:
        page_start:
          type: integer
          format: int64
          description: 该页第一个 item 的 ID
        page_size:
          type: integer
          format: int64
          description: 每页 item 数量
        has_prev:
          type: boolean
          description: 是否有上一页
        prev_start:
          type: integer
          format: int64
          description: 上一页第一个 item 的 ID
        has_more:
          type: boolean
          description: 是否有下一页
        next_start:
          type: integer
          format: int64
          description: 下一页第一个 item 的 ID

[andylizf]

And now the singular and plural problem of the code library is also worrying...