Grabbing this from a Slack post by twitter.com/kieran_nee - How to be a good dev in a studio

gistfile1.txt

## 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.