Last active
March 24, 2025 08:46
-
-
Save ryanzec/56312d302ede8eee4e914383717d8825 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# 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