[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Writing and maintaining a medium-sized code base
- From: Dirk Feytons <dirk.feytons@...>
- Date: Mon, 29 Aug 2016 10:32:56 +0200
Here's my experience from working on a Lua application of about 7000
real lines of code (excluding comments and blanks):
- As Daurnimator already said: keep the code simple (YAGNI principle).
- Write tests! Preferably automated ones. Do this from the start of
the project. Structure your code with testing in mind. Not only unit
tests but also functional/integration tests. If you have a lot of
tests it becomes easier to refactor your code. We mainly use lunit
(https://www.mroth.net/lunit/) and LeMock
- Write lots of comments. Not only the public functions of your
application, or the public functions of the internal modules but also
private functions and inside the functions. Explain the 'why'.
On 29 August 2016 at 02:57, tyrondis <firstname.lastname@example.org> wrote:
> 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.