[CodeStyle] Start all member variables with _

[ViMaSter]

Start all member variables with _ to distinguish them from local variables

---

I'd suggest limiting the _-prefix to private fields, not all member variables.
Also, instead of this rule, I think we should just cover all possible instances of names instead. For example JetBrains' defaults set:

• local variables and method parameters to camelCase
• anything outside to PascalCase
• private fields to _prefixedCamelCase
• const values to UPPER_CASE_SNAKE_CASE
• methods to PascalCase

I personally find those to be pretty intuitive.

---

EDIT: Addition for anything Unity/Ink specific:

• action linkes inside .ink files should use SCREAMING_SNAKE_CASE
  • as they are directly mapped to methods inside the ActionDecoder class, only these also use SCREAMING_SNAKE_CASE
  • Unity asset files should use PascalCase

[PhoebeMitchell]

I think we meant "private fields" when we said "member variables" anyway.
+1 for changing it to private fields.

It might make sense to include game related stuff. I.e. assets should be named in PascalCase, actions should be SCREAMING_SNAKE_CASE

[ViMaSter]

Ooo, adding the asset names is a super good idea!

Before that block I'd add:

• action linkes inside .ink files should use SCREAMING_SNAKE_CASE
  • as they are directly mapped to methods inside the ActionDecoder class, only these also use SCREAMING_SNAKE_CASE
  • Unity asset files should use PascalCase

[ViMaSter]

Updating this because of a good observation from @PhoebeMitchell in this PR:

These are the settings JetBrains' tools come up with when you point them at the current state of the codebase:

Notice how static readonly fields, even when private are set to UpperPascalCase, rather than _prefixCamelCase.
This would result in the following:

/// rather than
private static readonly List<string> _coolPreInitializedCollection = new List<string>() { ... }; // 1
/// we would have
private static readonly List<string> CoolPreInitializedCollection = new List<string>() { ... }; // 2

My initial suggestions was having private take precedence over anything else; however this would suggest, that non-modifiable fields (const, static readonly) come first, followed by visibility modifiers.

Personally I can see both reasons, and if it weren't for the fact that readonly items can still be modified using their member methods, I'd even go as far as making them SCREAMING_SNAKE_CASE, but that's not enforceable.

I think I'm leaning towards 2 of the example, for no other reason, that it's what I'm used to. Given that - if we decide against it - I'm happy to change to whatever we feel is more appropriate.