Semantic identifier naming

Use semantic, unambiguous names for every externally visible identifier (API parameters/endpoints, config/env vars, and build/version tags). Names must reflect meaning and supported behavior; if an operation is not supported, document that constraint next to the relevant field/behavior.

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

Use semantic, unambiguous names for every externally visible identifier (API parameters/endpoints, config/env vars, and build/version tags). Names must reflect meaning and supported behavior; if an operation is not supported, document that constraint next to the relevant field/behavior.

Application rules:

  • API naming: prefer consistent, descriptive snake_case names for parameters (e.g., parent_id, file_ids, page_size, orderby, desc) and keep them aligned with the actual request/response contract.
  • API constraints: when behavior is restricted, state it explicitly (e.g., “Changing file extensions is not supported.”) so users don’t infer unsupported semantics from the parameter/field naming.
  • Build/release naming: standardize version tag labels so stability and feature set are obvious.
    • Use vX.Y.Z for stable releases.
    • Use vX.Y.Z-slim for stable “slim” variants.
    • Use dev (not ambiguous labels like dev1) for development images.
    • Use nightly for nightly builds.

Example (Docker tag standard):

RAGFLOW_IMAGE=infiniflow/ragflow:v0.14.1
RAGFLOW_IMAGE=infiniflow/ragflow:v0.14.1-slim
RAGFLOW_IMAGE=infiniflow/ragflow:dev
RAGFLOW_IMAGE=infiniflow/ragflow:nightly

Example (API constraint wording):

POST /api/v1/file/rename
Body: { "file_id": "...", "name": "new_name.txt" }
Note: Changing file extensions is not supported.

Source discussions