Style

[StanHash]

Right now, style is inconsistent (I am to blame too). Here are some examples of diverging style elements found in fe8u:

file	author/year	braces	pointer declaration	switch blocks indent
hardware.c	camthesaxman/2018	Allman	type *var	no
ap.c	myself/2018	Java	type* var	no
animedrv.c	myself/2019	Allman	type* var	no
mapanim.c (first half)	NoahNelson/2021	Java	type *var	no
banim-main.c	MokhaLeee/2023	K&R ("Linux Kernel")	type *var	no
prep_itemscreen.c	Eebit/2023	Java	type* var	yes

We should probably agree on a consistent style (at least for braces and pointer declarations I think) and enforce it for contributions. The discussion of which style is, in my opinion, up to regular contributors (right now I think @MokhaLeee and @Eebit qualify).

My own (current) opinions regarding brace and pointer decl style are (sorry Mokha): I don't like K&R braces (inconsistent) and I don't like type *var style declarations (I prefer type * var and mind type* var less). Feel free to disregard them (I only rarely contribute directly these days).

Naming conventions are also something that probably should be made explicit.

[CT075]

I am personally of the opinion that the path of least resistance (both in terms of getting consensus and also logistically) is to use an automated formatter, like clang-format. This won't fix things like the occasionally CamelCase slip-up, but it

• Can be checked automatically on commit, instead of needing to be examined by hand
• Importantly, it is easy to retroactively apply such a styler to the existing codebase

As for the choice of which styler in particular to use (and indeed whether to listen to me at all -- I barely contribute, maybe you all enjoy arguing about bracket placement and type *var vs type* var), I would recommend picking something with presets. Twiddling the individual options is just more argument fodder.

[StanHash]

I have experimented with clang-format before for decomp (and indeed use it in mgfembp) and it works good for actual code but it (understandably) sucks for weird data initializers whose structure isn't reflected syntactically like procs or sprites. My "solution" was to manually enclose them in // clang-format off blocks.

[MokhaLeee]

But whatever, I don't particularly mind what kind of code style we adopt. If there is consensus, I may also follow to it.

[Eebit]

I think I would be happy with the formatting options that are already set up for mgfembp -- they seem sensible enough to me. :)

[MokhaLeee]

Hello guys, I wonder is there a clang format templete for this style? I'm considering write a clang format (not for decomp), for now I have made on:

Language: Cpp
IndentWidth: 4
PointerAlignment: Middle
BreakBeforeBraces: Allman
AccessModifierOffset: -4
IndentCaseLabels: true
Cpp11BracedListStyle: false
SpaceBeforeCpp11BracedList: true
AlignAfterOpenBracket: AlwaysBreak
AllowShortFunctionsOnASingleLine: None
AlignOperands: DontAlign
ColumnLimit: 120
UseTab: Never
SortIncludes: false