Coding Standards

Vibe coding policy

In the beginning I used LLM's only sparingly. Mainly as a tutor to learn Rust concepts which I then would apply myself. As the development progressed I used it more and more, also as a research tool.

I used VS Code as my IDE and experimented with some LLM extensions. That is where things went wrong. I gave them access to the codebase and they made a mess of it. That was a good lesson. I only used LLM's in a chatbot since and copy-pasted what I deemed was good and adjusted as needed. That was painful but safe.

About halfway development I got the change to use cursor.ai with Claude Code and never looked back (for coding). I set it up such that it would never make code changes by itself, but giving it full visibility into your codebase is a godsend.

As my trust in Claude Code grew I let it do tedious work in the codebase. Boilerplate stuff mainly. For design work I use it as a tutor/mentor again. I also use it as a research tool to investigate what is idiomatic in certain topics, like api design and such.

This is not what I would define as vibe coding. That is letting an LLM build everything from a description you give. As a 'safe' experiment I did let cursor.ai completely implement all unit and api tests for the server component. IT is safe as it does not touch the main code, and it takes the tedious work of maintainting test from me. It produced more code than the game itself, but that kind of makes sense as there are a lot of corner cases and api endpoints to test.

cq-server

cq-server is structured per resource (user, game, player,etc) with 3 layers:

  1. The API layer
  2. The Service layer
  3. The DB layer

when an api call comes in it is handled by the router at the start of the resource specific rust file inside the handlers folder. This router calls the handler function in the same file. This handler function typically has the following structure:

  1. api-doc
  2. the function signature with garde's where possible
  3. the access check. this will check is the user has permission to call this api endpoint and if it does, fetches the user record of the requester.
  4. call the service in the service layer
  5. format and return results if appropriate

The service layer for each resource contains all service functions for that resource. Aservice is typically structuered like this:

  1. Validations. run service specific validations. Abort when violated.
  2. Do transformations that are functionally needed
  3. Make changed to the DB using calls to the DB layer.
  4. Report where apprpriate (messages, emails, notification)
  5. Return to the API layer with return data where appropriate.

The DB layer takes care of all the SQL calls to the DB for whatever the services need.

Each layer can have helper functions. They are typically at the bottom of the files.