Die Oberfläche ist lokalisiert; Skill-Beschreibungen und -Dokumente werden per KI automatisch in Ihre Sprache übersetzt. Code, Befehle, Pfade und Fachbegriffe bleiben im Original, maßgeblich ist das Dokument des Autors.
Skills entdecken
Entwicklung · SKILL.md

nvidia-nemo-rl-linting-and-formatting

nvidia-nemo-rl-linting-and-formatting

Code style guidelines for NeMo-RL (Python and shell). Covers naming, indentation, comments, docstrings, reflection avoidance, and uv usage.

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill-Dokumentation

GitHub

name: nvidia-nemo-rl-linting-and-formatting description: Code style guidelines for NeMo-RL (Python and shell). Covers naming, indentation, comments, docstrings, reflection avoidance, and uv usage. license: Apache-2.0 AND CC-BY-4.0 metadata: when_to_use: Reviewing code style; writing or checking Python or shell code; 'is this naming right', 'docstring format', 'style violation', 'how should I format this', during code review. author: NVIDIA

Code Style

Style Guides

This repository is Python-first.

uv

Use uv run to execute scripts. Do not activate a virtual environment and call python directly.

Do:

uv run examples/run_grpo.py

Don't:

source .venv/bin/activate
python examples/run_grpo.py

Exception: Dockerfile.ngc_pytorch is exempt from this rule.

Python Standard

Code must conform to Python 3.13.13+.

Indentation

Indent with 4 spaces. Do not use tabs.

Naming

KindConventionExample
Filessnake_casesome_file.py
ClassesPascalCaseclass SomeClass
Functions/methodssnake_casedef my_awesome_function():
Local variablessnake_casemy_variable = ...
Variables starting with a numberprefix kk_99th_percentile = ...
Global variablesupper snake_case + prefix GG_MY_GLOBAL = ...
Constantsupper snake_caseMY_CONSTANT = ...
  • Avoid shadowing variables declared in an outer scope.
  • Initialize all externally visible members of a class in the constructor.

Comments

  • For interfaces used outside a file, prefer docstrings over comments.
  • Comments are for code within a function or file-local interfaces.
  • Commented-out code must have a comment explaining why it is commented out. Otherwise remove it before merging.

Docstrings

Use Google style docstrings (parseable by Sphinx).

Enforce Keyword Arguments for Ambiguous Parameters

When a function has multiple parameters of the same type that could easily be swapped by mistake, use a bare * to force keyword-only arguments starting from where the ambiguity begins. This prevents callers from accidentally transposing arguments.

Don't:

def loss_fn(input: Tensor, cp_group: ProcessGroup, tp_group: ProcessGroup, cp_rank: int, tp_rank: int):
    ...

# Caller can silently swap cp_group/tp_group or cp_rank/tp_rank
loss_fn(x, tp_group, cp_group, tp_rank, cp_rank)  # wrong order, no error

Do:

def loss_fn(input: Tensor, *, cp_group: ProcessGroup, tp_group: ProcessGroup, cp_rank: int, tp_rank: int):
    ...

# Caller must name every argument — swaps are impossible
loss_fn(x, cp_group=cp_group, tp_group=tp_group, cp_rank=cp_rank, tp_rank=tp_rank)

Avoid Reflection

Do not use reflection when functionality can be achieved without it.

Don't:

def make_complex(*args):
    x, y = args
    return dict(**locals())

Do:

def make_complex(x, y):
    return {'x': x, 'y': y}
Gespeicherte Skills