@@ 1,79 @@
This page describes the Forge development mindset.
> A minimal viable program is the smallest program that solves a particular
> problem. It is small and beautiful. It has no additional features.
> If you removed a single feature it would be totally useless. If you added a
> new feature that feature would not be essential, you could use the program
> without making use of the new feature.
> [Minimum Viable Programs - Joe Armstrong][minimum-viable-program]
Computer graphics software is a complex domain with many working parts that are
often tightly coupled (or just badly designed) for the sake of performance or to
satisfy obscure edge cases. With Forge, we take a step back and challenge the
conventions of traditional computer graphics software design.
Developers who are keen to write high quality and experimental software are more
than welcome to contribute. It is an opportunity to entirely rethink any
approaches made in existing solutions, and build novel ideas by returning to
[first principles][first-principles]. We are conservative in that we do not try
to solve many problems, but keep the problem domain small, focusing on tackling
a few problems well and carefully.
Designing components as beautiful, "minimum viable programs" is possible, it
just demands some patience and forethought.
## Best practices
**Write clearly.** Clarity here refers to elements of the program such as
readability and control flow. Most of the code we write on a daily basis is
really for other humans (including your future self) to read and maintain, the
less time and cognitive load it takes for others to grok, the more time can be
spent on actually hacking away.
This should not discourage the use of complex mathematics/algorithms or advanced
language features where it makes sense, although it is helpful in these
situations to include additional commentary to help less familiar/experienced
developers. Comments are also instrumental on the occasion when readability is
sacrificed for performance.
Assume other developers working on the project can read and understand most of
the code. This means avoiding "fluff" comments. Name variables, methods, etc.
clearly and your code will be naturally "self-documenting".
**Exercise discipline.** Satisfaction should not come from merely getting
something to work, but instead from having it work elegantly. If it means
spending more time on the task, then, by all means, take your time to iterate,
revisit, and rewrite where necessary. Try to strike a balance, but prefer
quality over speed. To reiterate, if something is a hack, then work on it until
it is nothing short of simple and beautiful.
Use common sense to make decisions. There is intentionally no mention of coding
style, just stick to the style of the existing code. The maintainer has absolute
say over formatting, this avoids any bottomless debates and avoids wasting time
trying to address formatting-related changes. When in doubt, loosely refer to
the [Linux kernel coding style][linux-kernel-coding-style].
Unlike the [suckless philosophy][suckless-philosophy], **frugality is a
non-goal**. Having fewer lines of code is ideal as it encourages re-use and
simplicity, leaving less to maintain. On the other hand, it can often negatively
affect clarity, which should be considered the primary motivation of Forge.
## Related material
- [suckless philosophy][suckless-philosophy]
- [Mike Acton - Data-Oriented Design](https://youtu.be/rX0ItVEVjHc)
- [Casey Muratori - The Thirty Million Line Problem](https://youtu.be/kZRE7HIO3vk)
- [Jonathan Blow - Preventing the Collapse of Civilization](https://youtu.be/pW-SOdj4Kkk)