FOSS gamedev and creative worlds

Not all of Minetest's code style is well-defined at this point. For 95% of matters we defer to the Linux kernel code style, since it seems to be somewhat of a standard among open source projects, is low friction, and tends to make a lot of sense. However, there is a problem with the Linux recommended macro line continuation style. The Linux style dictates a tab stop spacing of 8, and further, alignment indentation is done using tabs, so it always comes out consistent for Linux. For our own alignment indentation we override this, using spaces, like so:



However, if the tab size is set to 8 rather than 4, this same code would display as:

which is argued by some to be broken and ugly.

So, the proposed solution is to not align macro line continuation characters at all, using a single space instead:


I argue that, while this style may be more consistent, it is uglier and less readable than the broken version, and makes the code equally ugly when viewed under any tab stop spacing.

What do the rest of you think?

Here is the associated PR.

For me the backslashes are visual clutter that gets more intrusive and disorientating the closer to the code it is. Although aligned may at times become unaligned and messy, at least it is at a reasonable distance away from the code, the misalignment is far less irritating than close backslashes.

Why didn't we use tabs too?

You can change your editor's behaviour regarding tabs to different modes:
1. The "tabstop" mode. This is where every "tab" will move the following text to the next "tabstop". Its the original way the tab key has been invented for, back then still on typewriters, and the linux code style guidelines are designed for tabstops that are configured for 8 spaces exactly.
The problem with tabstops on the right is, that the spacing may be completely uncertain.
So, in the best case, tabstops can help you with alignment:

but what happens with this example:

you will have to use multiple tabs on the second line! Thats even worse than using spaces, because you'll never be certain how much tabs to use. Imagine if you watch the same file, just with another number of spaces configured to tabs:

So, tabbing style is broken here.
Elastic tabstops would help against this, but we shouldn't introduce completely new concepts.
2. The "constant space" mode. In here every tab character is associated a fixed number of characters.

I think, tab usage should be portable across all configurations, whether its "tabstops" or "constant spaces" (and both feature countless submodes). My proposal would even support "typewriter style" tabstops, that can be set manually (like in word): 1 cm for the first tab level, 1.5 for the second, and 2.7 for the 3rd.
Tabs give flexibility. We shouldn't take it away again. Moving those "ugly" characters doesn't *re*move them, they even create more problems.
Its a dead end if we want to align tab level differences on the left with spaces on the right.

The \ character is similar to the ; character, you don't align to that either. Yes, it looks different at first glance, but I'm sure you get accustomed to it.

… why are there backslashes needed at all?

In minetest, we use backslashes at two points:

1. For C preprocessor macros. The examples you see above aren't regular C code, they are preprocessor macros. You can use those to spare ugly repetition of similar code, like with functions, but in some ways different (for example you can use internal variables without passing, but its in no way an actual replacement, you have no stack, and you don't have any way to check for the type of your "arguments"). It is simply a part of the C standard, that if there is a new line without a backslash, the macro is considered to be terminated.

2. For the android makefile rules (The PR linked above is about those). Here, having multiple lines without a backslash between will start them in different subshells instead of executing them in one, meaning you can't use local variables, you'll lose pwd changes (the 'cd' stuff), and if constructs won't work (Btw. if starting in subshells would be sufficient for us, we won't need the ";"s either).

Also, it would theoretically work to cram everything into one line, but that's obviously a bad choice.

est31 wrote:It is simply a part of the C standard, that if there is a new line without a backslash, the macro is considered to be terminated.

I never really used C. Thanks for the explanation!

So then the backslash is for escaping the newline, right? I’d use the last variant then (single space followed by the backslash). Oh, and spaces instead of tabs. Is there something like PEP-8 for C?

Linuxdirk wrote:

est31 wrote:It is simply a part of the C standard, that if there is a new line without a backslash, the macro is considered to be terminated.

I never really used C. Thanks for the explanation!

So then the backslash is for escaping the newline, right? I’d use the last variant then (single space followed by the backslash). Oh, and spaces instead of tabs. Is there something like PEP-8 for C?

This isn't Python, we follow the Linux code style. http://dev.minetest.net/Code_style_guidelines

Also, I always use tabs in python due to the reliance on indentation - editors always seem to muck up and remove spaces causing inconsistant indentation errors.

rubenwardy wrote:editors always seem to muck up and remove spaces causing inconsistant indentation errors.

It's alarming if an editor changes the code without beeing told to do so.

I guess we could require that right-alignment be one tab at EOL followed by the required amount of spaces for alignment. I doubt anyone would remember to do it though :)

I think git will see this as whitespace error, Zeno.

I have a preference for one whitespace before backslash when we are developping, it's better and faster, but i also agree that align backslash permit a better reading of the code. Then i think we should use the secondary, maintenance is better than faster coding.