Skip to content

Instantly share code, notes, and snippets.

@nickludlam

nickludlam/gist:7d3d8bf83fd5f6b0768bf04ddf11bc9f

Created January 17, 2024 19:13
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save nickludlam/7d3d8bf83fd5f6b0768bf04ddf11bc9f to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save nickludlam/7d3d8bf83fd5f6b0768bf04ddf11bc9f to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. nickludlam created this gist Jan 17, 2024.
    53 changes: 53 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,53 @@
    ## Good Conduct

    - Fix all warnings in your code before commits
    - I don’t want to have to turn on Warnings as Errors, but I will if I have to discuss this more than a few times.
    - Keep an eye on runtime warnings. If they’re ones you’ve introduced, fix them before committing.
    - If they’re ones you think you can fix, please fix them.
    - If you aren’t sure what’s causing them. Let the rest of the team know so someone who knows the root cause can fix them.
    - Check your references for NULL and handle gracefully, don’t just assume they exist.
    - If you see something broken
    - FIX IT if you are confident you know how and it won’t massively impinge on your current work
    - Though have a quick check if anyone else is working on it
    - Let Production or QA (when we have QA) know about it
    - Keeping the game working is EVERYONE’S responsibility.
    - Keep an eye on Performance as much as possible
    - Only do as much "work" as you have to
    - Limited life tasks or updating Coroutines instead of Updates where possible (very C# focused)
    - Operate on as small a data set as possible at once
    - CACHE data where sensible
    - If you’re working on anything that may affect performance, keep an eye on the profiler.
    - If you can avoid using Reflection at run time, do so.
    - Call expensive functions as infrequently as you can get away with and cache the results
    - Consider if work is something that can genuinely be passed off to a background thread or Job system.
    - Candidates for this are
    - queries on large data sets
    - Large amounts of work that don’t access any Engine specific functionality
    - This is important, can't rely on built in functions always being threadsafe.
    - If an engine feature is potentially just a wrapper for a language feature, USE THE language feature! The cost of wrapper calls can really add up when done frequently.
    - For example in Unity [Mathf for example is almost entirely just wrapper functions](https://docs.unity3d.com/ScriptReference/Mathf.html)
    - Consider if you genuinely have to write new code:
    - Does the project contain something similar that could be extended cleanly and safely? Or refactored to work for multiple similar use cases?
    - For example, if code that’s almost the same exists, can you extend the base code to facilitate all your desired behaviour based on provided data simply & safely?
    - Are there already extensions/attributes/approaches that could be used instead?
    - Does the Language itself contain something that can do it for you?
    - Why use replaces if you can use string.Format in C# for example?
    - Refactoring
    - If necessary, do so as separate from new features or bug changes if at all possible.
    - Ideally maintain it as easily undone and checked as possible
    - Minimal points of return
    - Where possible don’t return out of the middle of a function.
    - It makes maintenance and extension of existing code a lot easier
    - crucial data setting or function calls won’t be missed by patched in “fixes”
    - Early Outs based on state are acceptable
    - Avoid unnecessary allocations.
    - Switch statements should always have a default. 
    - When something is a dirty hack, leave a comment with something like this syntax (with your own name inside the parenthesis):
    - // HACK(Name): Bla bla bla
    - Avoid commented out code. It only confuses and inevitably goes stale fast
    - Delete it and retrieve from commit history if you need to
    - Graceful failure is preferred where-ever possible
    - Data will break, handle it and log about it!
    - Keep changes small where possible
    - Change & refactor incrementally
    - Consider writing tests to validate that the code still behaves as required.