Recommandations regarding Inform 6 style

Authoring Inform 7
#1

I was wondering if there was some kind of accepted Inform 6 “style guide”. The DM4 never quite states what kind of casing, indentation and so on one should use. (It only tell that identifiers are not case-sensitive.)

So here what I guessed from the examples and the library. Is the following what people expect in a third-party library? It may not be important, but I like to have something consistent.

Whitespace

Inform 7 and its I6 templates use tabs, so I guess the official “Graham Nelson” way is to use tabs. But the I6 library uses 4 spaces, so I suppose both are acceptable.

There’s usually a space after the opening of a routine [. In the declaration of a routine, some people seem to separate the arguments of a routine and its local variables with more than one space (2 or 3), or to put the locals on a separate line.

I guess it’s better to have whitespace around operators, but the I6 templates are inconsistent about it.

Casing

  • Directives have an initial upper case.
  • Routines use PascalCase (e.g. ChangePlayer), but properties use snake_case (e.g. react_before).
  • Constants are in all caps and with underscore (e.g. GPR_NUMBER). Globals use snake_case.
  • Rooms are in a mix of PascalCase and snake_case in the DM4 (e.g. Square_Chamber). Other objects (in-world things) are in snake_case. Classes and abstract objects are in PascalCase.

Namespacing

Lastly, how would a library author make sure their routines and variables don’t clash with other libraries? Let’s say I’ve written a library called MyLib.

I’ve seen people prefix their routine, like MyLibRoutineOne. Some I7 extensions add an underscore, if I recall correctly: MyLib_RoutineOne.

We could also create an object that will contain the routines and variables:

Object mylib
    with
        RoutineOne [;]
;

And now we can call it with mylib.RoutineOne(). The drawback is that an additional object take more memory, and I believe embedded routines can have less parameters than normal routines. (Also, they return false by default instead of true, but that should rarely have a consequence.)

So what are your thoughts about this? Do you have other considerations I didn’t think of? Or maybe I shouldn’t care that much, since identifier are case-insensitive?

1 Like
#2

I6 is close enough to C that many people (including Graham) bring over their C coding style habits, which of course vary wildly.

Also remember that the I6 library has a long history. It was originated in the 90s on RiscOS, using I have no idea what code editor, and then been worked on by several people on several other OSes and editors. It’s not all that consistent internally.

The library namespacing issue is worth thinking about. A prefix string (on all global symbols) is the common convention, I’d say.

3 Likes