Re: Writing and maintaining a medium-sized code base

[Marc Balmer <marc@...>]

> Am 29.08.2016 um 02:57 schrieb tyrondis <tyrondis@icloud.com>:
> 
> Hey *,
> 
> I would like to get your experiences on how you write and maintain code that goes beyond a simple script and make sure that it is stable, bug-free (ideally) and does not break from any chances.
> 
> I chose Corona SDK as a game engine for a game I want to write and it uses Lua as its scripting language. I really like the language, however, coming from a mostly statically typed language background (Java, C++, C#) I always feel a bit insecure about my Lua code. There is this constant feeling of uncertainty about whether I broke something with a change and I will not discover it because I do not happen to bring the interpreter to that exact spot to trigger the issue.
> 
> By no means I want to start a debate about dynamically vs statically typed languages. I like both approaches and I enjoy Lua a lot. I simply want to get some best practices on how to write great quality Lua code on a larger scale.
> 
> Having a great coverage of unit tests would be a great start, however, it is a bit difficult with Corona, as most of its APIs (Graphics, Audio, etc.) are only available inside the embedded system and I do not want to mock everything.
> 
> Looking forward to a great discussion.
> Tyrondis

We maintain a codebase with ~80'000 lines of Lua code and ~230'000 lines of C code
(eight years of continous development by up to five people).

We keep that in a subversion repository where we have three branches:  head, testing,
and, stable.  We develop in head, once something works, it goes into testing.  From testing
we build binary packages that go to our software distribution server.  Test machines then
load that code, and we can test everything on real hardware.  Once testing is done, the
feature goes into the stable branch, and eventually we make a release, which again is
pushed to the distribution servers.

We don't believe in automated testing and such, but that is mostly because our software
a) is very thoroughly tested by humans, and, b) there is a lot of interaction with the
environment or hardware devices as bizarre as coin rejectors or scales that wheigh
african elephants.  It's not strictly easy to write unit tests for those.

When we need something new, let's say a new protocol or a new binding to some piece
of third party software, e.g. wayland, then we usually do it this way:

1) We design the Lua API, i.e. we write a Lua program that uses the not-yet existing
module.  We design that with Lua in mind, how we would like it to look in Lua.
2) Now we usually design a C level library that implements the feature.
3) We create a Lua binding to the library, adding all the nice things Lua allows us to do.

This way we almost ever the functionality available to C code as well to Lua code.
That has paid off many times in the past.

We use a clear and documented code style, so all of our code should be readable. We
loosely follow the NetBSD KNF style, which we adopted for Lua as well.  E.g. we intent
with tabs and a tab is 8 characters wide.  We avoid unnecessary brackets in code.

We try hard to keep all code simple and readable.  That means maintainable code, which
means less problems.  We are not shy to toss away code we don't use anymore.

Then we do constant code review and when we found a bug or problem, we go to all
our codebase to check if we made the same mistake anywhere else.

- mb