DocumentationdevelopmentBest Practices

Development Best Practices

This checklist-style reference highlights the habits that keep QBCore projects maintainable over the long term. Adopt these pat terns early to reduce regressions, improve collaboration, and ship confident updates.

Keep Resources Modular

  • Use clear prefixes. Follow the qb-* naming convention and keep each resource focused on a single gameplay system.
  • Isolate shared utilities. Export shared functions from a lib/ or modules/ folder instead of duplicating logic.
  • Document exports. Maintain README files or inline comments describing every export so other teams know how to integrate.

Manage Configuration Like Code

  • Validate everything. Run the Config Validator before every release to catch missing items, inc orrect job grades, or inconsistent pricing tables.
  • Version control configs. Commit configuration files alongside code so you can trace when balance changes landed.
  • Use environment overrides. Keep secrets and server-specific values in .env files and read them at runtime instead of har d-coding values.

Build Robust Event Flows

  • Design for failure. Guard every event handler against missing arguments and invalid states. Never assume the player or veh icle exists when the event fires.
  • Log critical transitions. Emit debug statements for state changes, cooldown resets, and payout calculations.
  • Trace with the Event Debugger. Use the Event Debugger during development to confirm your client an d server events fire in the expected order before going live.

Protect Server Performance

  • Avoid tight loops. Use CreateThread with sensible Wait intervals and exit early when work is complete.
  • Batch database access. Prefer asynchronous queries and reuse prepared statements. Offload heavy jobs to queued workers whe re possible.
  • Profile regularly. Schedule routine sessions with the Event Debugger and built-in profiling commands to catch regressions before players notice.

Collaborate Deliberately

  • Use pull requests for every change. Code review surfaces edge cases and keeps knowledge shared across the team.
  • Write migration notes. When introducing breaking changes or new configuration keys, document the rollout steps in your res ource repository.
  • Automate formatting. Configure Prettier/ESLint (or equivalent) in your editor so style issues do not distract from code re view.

Release Readiness Checklist

  1. All relevant configs pass the Config Validator.
  2. Critical event paths were verified in the Event Debugger.
  3. Logs contain actionable error messages and are free of noisy spam.
  4. Database migrations include rollback plans.
  5. Resource manifest versions were bumped and changelog entries written.

See Also

DebuggingPerformance Tuning