Skip to content

Instantly share code, notes, and snippets.

@ryanzec
Last active March 24, 2025 08:46
Show Gist options
  • Save ryanzec/56312d302ede8eee4e914383717d8825 to your computer and use it in GitHub Desktop.
Save ryanzec/56312d302ede8eee4e914383717d8825 to your computer and use it in GitHub Desktop.
# coding guidelines
- follow existing coding standards, do not refactor existing coding standards to something else
- always perfer using functionality provides by libraries / tools first, introduce to libraries / tools secondary, and write custom code third unless otherwise specified
- write code in the context of that code being pushed into a production environment
- always explore simplier solutions before complicated ones
- always try existing patterns instead of introduce new ones when possible
- using naming that make code self commenting, avoid useless comment that can be easily gleaned by just reading the code
- when commenting code, only do it when needed (like for complex algorithms) or when you need to explain the why, not the what
- avoid code duplication, search for existing util methods / component to be able to re-use (it should still follow screenshot but does not need to be perfect)
- only make update that are required for the requested task, do not modify other pieces of code unless needed for the task
- when fixing bugs or making follow-on change, make sure to not introduce bug previously fixed
- keep the codebase clean and organized, if you and new generic functionality, place it is a utils file, if you are create a generally re-usable component, create a component folder / files for it
- avoid large components (+400 lines), break up component into smaller ones and keep component to 1 per file
- avoid breaking up component (even large one) if it make reason around the functionality of that component overly complex
- never mock anything unless it is for a sandbox file or testing file
- when adding a new npm package, always save the package using use the latest version and exact version (no auto update version syntax)
- always think about other areas of the code when being requested to do a tasked change
- always perfer early exiting over else statements or conditional nesting
- avoid abbrivations for most things, `id` is an ok abbrivation and initialisms (like UI) are also ok
- make naming descriptive enough to be clear but not overly verbose (so `clickEvent` instead of `event` or `clickButtonEvent`)
- make sure to have a blank line before any return / conditional control statement (`return`, `break`, `continue`, etc.)
- if you search for a file and can't find it, ask for a reference to the file before attempting to create a new file
# speciif coding guidelines (frontend)
- css should use `kabab-case` but use `camelCase` when imported into javascript / typescript
- use proper typescript typing
- favor types over interface whenevery possible
- if running into a typing issue, as a last resort you can just explicit cast it as needed (without using unknown) and if that fail then you can use any, add a comment above the cast / any in the case that it should looked into for proper typing
# tech stack (frontend)
- solidjs / typescript for frontend code
- vite for build system
- pnpm for package management
- vitest for unit testing
- playwright for ui / component testing (using the sandbox system)
- css modules for styling
# speciif coding guidelines (game dev)
- uss should use `kabab-case`
- names for elements in uxml should be PascalCase
- if your changes require updates to game objects or anything in the unity editor, call them out in the final review of changes so I know to do them
- for values that are used multiple times, avoid magic number or strings, instead create consts for those and use that in the code
- if there is editor specific code in code that gets compiled into a production build (like `OnValidate()` methods), make sure to wrap that code in `#if UNITY_EDITOR` so production build don't break
- event handler for signal show be named as `On[FULL_SIGNAL_NAME]`
- always favor using property of `{ get; private set; }` vs just a private field (make serialization easier) expect for mono behaviours fiels that need to be exposed in the unity editor
# tech stack (game dev)
- unity 6.1
- a star pathfinding project
- use yaml for data
- odin for custom editor functionality
- ui toolkit for in game ui functionality
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment