Nitrox
Nitrox copied to clipboard
Consistent coding style
Put a styleguide together covering both formatting (eg. settings for the built in formatter) and syntactical matters. Below is a list of inconsistencies and changes I've noticed in the project.
Formatting:
- Spaces between keywords and parentheses
if (
vsif(
. - Unnecessary (trailing) white space (VS removes this on format).
- Sorting of fields and methods (dependent on access modifiers mostly).
- Use docstrings
///
instead of regular (//
) comments.- If needed, use the right syntax to refer to variables etc.
Syntactical / formatting (mixed):
- Unnecessary use of
this.
- Braces around one liners (and ofc method body on a separate line). Single line method expressions are OK too.
- Parens around assignment expressions
foo = (bar != none);
. - Unused (and unordered)
using
statements (VS can fix this as well). - Unnecessary casts.
- Write field initializers at declaration instead of in the constructor (if applicable).
public readonly List<string> SomeThings { get; } = new List<string>();
versus assigning it in the contstructor. - Short notations:
- Null propagation such as
foo = bar ?? cake;
. - Ternary if statements such as
foo = bar < 0 ? bar : foo
;. - Safe navigation operator
var foo = bla?.something;
.
- Null propagation such as
Safe code practices:
- As strict as possible access modifiers (to indicate usage and prevent ambiguity):
- Use
static
when a method doesn't (need to) touch local variables. -
const
andreadonly
where possible. -
public
vsinternal
, with multiple libraries going on this might be a good idea. -
private
on 'unity functions' that should not be called by our code (Awake
,Start
, etc) - Remove
private set;
when a property is only assigned in the constructor (or directly). -
sealed
classes? I'd say that's out of scope, until we start allowing plugins and such (or build a complete modding framework).
- Use
- Check for NRE's everywhere;
- Especially when retrieving datastructures from game-code. The game is constantly in development, and things will change. Defensive programming practices are a must to aid in debugging and correcting these changes later on.
Naming:
- CTS or aliases (
Int
vsint
and so on). - lowerCamelCase for everything private, UpperCamelCase for everything else?
Other:
- Use of inline functions vs defining a full function with types etc.
- Also applies to lambda notation:
private bool cake() => foo != null;
. - Sort
Compile
items in csproj files; this reduces faulty decisions in merge conflicts. - Use file-scoped namespace declarations for new code.
And remember, it's not so much a matter of preference as it is a matter of consistency.
Most of those rules could be enforced with a stylecop ruleset: https://github.com/DotNetAnalyzers/StyleCopAnalyzers
Violations of those rules would then pop up as warnings (or errors if you like).
If you guys think that this would be useful, i could give it a try.
I could go through the modules one by one and enforce this style.
We should first discuss code style and create the code style files that visual studio and/or intellij use so they can enforce it. Fixing code style now will just lead to PRs changing it again which would be a waste of time.
Closing as this got stale and fixing code-style is an ongoing process between the preferences of all Nitrox developers.