Debugging Go code built without optimizations is easier, as mentioned on
https://go.dev/doc/gdb#Introduction:

> When you compile and link your Go programs with the gc toolchain on
> Linux, macOS, FreeBSD or NetBSD, the resulting binaries contain DWARFv4
> debugging information that recent versions (≥7.5) of the GDB debugger
> can use to inspect a live process or a core dump.
>
> Pass the '-w' flag to the linker to omit the debug information (for
> example, go build -ldflags=-w prog.go).
>
> The code generated by the gc compiler includes inlining of function
> invocations and registerization of variables. These optimizations can
> sometimes make debugging with gdb harder. If you find that you need to
> disable these optimizations, build your program using go build
> -gcflags=all="-N -l".
>
> If you want to use gdb to inspect a core dump, you can trigger a dump
> on a program crash, on systems that permit it, by setting
> GOTRACEBACK=crash in the environment (see the runtime package
> documentation for more info).

As mentioned on
https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline
and
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206,
POSIX defines a line as

> A sequence of zero or more non- <newline> characters plus a terminating <newline>
> character.

When a file does not terminate with an empty line, `Git` commands such
as `git diff` show the message `No newline at end of file`.

This commit adds a CI job `pre-commit` to enforce the formatting.