GDScript: Recommend Spaces instead of tabs for indentation

[fcole90]

Describe the project you are working on

None, in particular, I'm just learning Godot.

Describe the problem or limitation you are having in your project

1. The default for the GDScript text editor is to use tabs for indentation, and this is according to the guidelines. This leads to issues in some situations, where people want to visually align some elements in the code.
   See issues:

   • [4.0dev] GDScript - Mixed tabs and spaces not allowed in multiline declarations godot#49171
   • Mixed tabs and spaces no longer supported for multiline declarations godot#30937

2. Most people who know Python already use spaces for indentation (according to guidelines), which can make it easier for them to learn GDSCript.

   • Python official guidelines: https://www.python.org/dev/peps/pep-0008/#indentation
   • Google guidelines for Python: https://google.github.io/styleguide/pyguide.html#s3.4-indentation

3. The width of a tab is not standardised, while one space is always 1 character long, which makes its use more intuitive.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I want to propose to recommend whitespaces instead of tabs for indentation. This proposal would make GDScript more in line with current established standards of similar programming languages and would mitigate a class of bugs.

The bugs at [1] wouldn't happen, because there would be no tab in a file.

Using spaces is as convenient as tabs, in fact, when changing the setting of the Text Editor to Spaces, pressing the TAB key, inserts 4 spaces (or the amount one specifies as indentation), so it's as quick and as easy as having a real tab, but with the added benefit that no such issue as the ones mentioned before would cause concern.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

1. In the GDScript guidelines page, change the formatting to say:

Use *4 Spaces instead of Tabs for indentation. (editor default)
- https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_styleguide.html

2. In the editor, change Text_Editor.Indentation.Type from Tabs to Spaces

Code with tabs and spaces

for i in range(10):
	print("hello")
	var my_list = [i * 1,
		       i * 2,
		       i * 3]

Syntax error: Error: Mixed use of tabs and spaces for indentation

Code with only spaces

for i in range(10):
    print("hello")
    var my_list = [i * 1,
                   i * 2,
                   i * 3]

Runs correctly

If this enhancement will not be used often, can it be worked around with a few lines of script?

Any user can change it already: from the top menu, find and press on Editor -> Editor Settings.

It will open a new window and you will find on the left, the item Text Editor with subitem Indentation. There you can change Type from Tabs to Spaces. I recommend leaving Size to 4 and enabling Draw Spaces.

Changing the guidelines would standardise this behaviour.

Is there a reason why this should be core and not an add-on in the asset library?

Because I'm suggesting a change to the guidelines of a core component (GDScript)

[YuriSizov]

The width of a tab is not standardised, while one space is always 1 character long, which makes its use more intuitive.

This is actually a benefit, because many people prefer different indentation lengths in their code, and many code editors allow to control the size of the tab to accommodate that.

The default for the GDScript text editor is to use tabs for indentation, and this is according to the guidelines. This leads to issues in some situations, where people want to visually align some elements in the code.

It is better to provide universal guidelines on how to align code in these situations. Looser syntax usually creates unnecessary points of conflicts where people start to argue which superficial code style is better. Tabs vs Spaces is precisely one of these points. It is generally easier for people to adapt to a forced style than to try and adjust themselves after adapting a personal style before starting to work in a team.

Most people who know Python already use spaces for indentation (according to guidelines), which can make it easier for them to learn GDSCript.

GDScript is not Python so this holds no real weight here. There are many other languages that people can come from and none of them is less important in terms of helping people to migrate to GDScript.

[Calinou]

The GDScript style guide is of the opinion that excessive code alignment is counterproductive (most of the time). If people disregard the style guide and try to align everything even when it doesn't make sense, we can't do anything about it.

For instance, multiline arrays are better written in this form since it doesn't require you to re-indent your code if the variable is renamed:

var some_array = [
	1, 2, 3,
	4, 5, 6,
]

With the form originally described in the issue, you need to realign all the lines below the first line whenever the variable name changes:

var some_array = [1, 2, 3,
				  4, 5, 6,
]

Since the Godot script editor doesn't support multiple cursors yet (and that won't happen for a while), it's a pain to realign those lines with spaces. I believe good formatting should lean itself to easy refactoring 🙂

[fcole90]

It is better to provide universal guidelines on how to align code in these situations. Looser syntax usually creates unnecessary points of conflicts where people start to argue which superficial code style is better. Tabs vs Spaces is precisely one of these points. It is generally easier for people to adapt to a forced style than to try and adjust themselves after adapting a personal style before starting to work in a team.

@pycbouh My proposal is indeed not to loosen the syntax. You say that a forced style can be better to keep things together. Just I think such style being spaces rather than tabs would be beneficial.

[fcole90]

The GDScript style guide is of the opinion that excessive code alignment is counterproductive (most of the time). If people disregard the style guide and try to align everything even when it doesn't make sense, we can't do anything about it.

Does this mean you would like to close godotengine/godot#49171 as wontfix?

For instance, multiline arrays are better written in this form since it doesn't require you to re-indent your code if the variable is renamed

Indeed, formatting in the way you suggest is a good idea, regardless of spaces vs tabs 😊

Since the Godot script editor doesn't support multiple cursors yet (and that won't happen for a while), it's a pain to realign those lines with spaces. I believe good formatting should lean itself to easy refactoring slightly_smiling_face

Yes, but with the coding style you suggest, the indentation of both tabs and spaces can be changed by selecting multiple lines and pressing TAB or SHIFT+TAB 😊

[Calinou]

Does this mean you would like to close godotengine/godot#49171 as wontfix?

The bug should still be fixed (that script works fine in current 3.x), but I don't think the indentation recommendations in the style guide will change.

[fcole90]

In the end, I see your points and have no other arguments in favour of spaces (rather than personal taste) 😊

[bluenote10]

The main argument would be that almost all modern style guides have settled on spaces over tabs. Python, C++ (Google Style Guide, LLVM, ...), Rust, the JavaScript & TypeScript communities, Ruby, Nim...

[LikeLakers2]

If I might throw my two cents in: I don't think I can agree with recommending spaces.

To explain: I would rather not have to deal with third-party GDScript code that was written with spaces, as I am personally used to tabs. I don't mean that as "I won't use it", but that if I'm editing it, I would rather not be forced to use the spacebar just so the script can work, nor would I enjoy converting everything over to tabs.

To add on to that, I don't like the extra time it would take to indent my code with spaces, compared to just hitting tab once or twice -- not to mention that my spacebar already receives enough abuse in Minecraft. ( :P )

[fcole90]

@LikeLakers2 there's a huge misunderstanding about indenting with spaces. You don't actually need to add spaces one by one with the spacebar.

E.g. If you change the Text Editor settings of Godot to use Spaces to indent (procedure described in the first comment), the editor adds 4 spaces¹ every time you hit TAB. I only use spaces for my indentation and I never use the spacebar to achieve that. Also, if you copy/paste code with tabs instead of spaces, the editor replaces everything properly as soon as you save your script.

Actually, the code in the Introduction tutorial (and I assume other ones too) already uses spaces for indentation, probably you never realised that, as the editor is smart and always converts everything according to your indentation style settings.

So, while I understand your concern, the editor (as most modern editors like VS Code, PyCharm, Rider) is smart enough that you don't notice the change and you don't actually need to use the spacebar at all, TAB just outputs instead of \t 😉

[1] I just say 4 for the sake of simplicity, you can set the number to what you want. 4 spaces are the most common indentation in Python, 2 in Javascript. If you change your mind at some point in the future, changing the indentation setting and saving again (or pressing a conversion button) is often enough for modern editors to auto-switch to the new setting.

[LikeLakers2]

@fcole90 I'll admit I didn't read much of this issue before commenting, so thank you for correcting me.

However, in any case, I'm not convinced. The use cases presented in the original post, while reasons why you might want to use spaces, don't really feel like the rule. They feel like the exception to the rule. They don't convince me that we should be recommending something else.

[fcole90]

@LikeLakers2 Indeed, the arguments for spaces over tabs are not that strong, and I realise that such case is more an exception, and possibly bad style, rather than a typical use case.

In the end, the matter is pretty debatable and up for opinions. As I see, the only real argument for recommending spaces over tabs at the moment is more a matter of following the standards of other languages, but if that really matters, and to what extent, is up for opinions.

[aaronfranke]

@LikeLakers2 @fcole90 Nobody presses the space bar multiple times. Space users press tab to get spaces, and tab users press tab to get tabs. Nobody is proposing that users press the space bar multiple times, that's just horrible. Pressing tab to get 4 spaces is not a magic solution or compromise, that's what spaces users already do.

1. The default for the GDScript text editor is to use tabs for indentation, and this is according to the guidelines. This leads to issues in some situations, where people want to visually align some elements in the code.

At least in GDScript, alignment is considered bad practice. It's far too cumbersome to work with whether you're using tabs or spaces. In your code example above, I think it's much more readable to do this:

for i in range(10):
	print("hello")
	var my_list = [
		i * 1,
		i * 2,
		i * 3,
	]

Plus, the above is MUCH friendlier to version control, since it allows you to rename the variable without showing a diff for changing the first item, and vice versa.

2. Most people who know Python already use spaces for indentation (according to guidelines), which can make it easier for them to learn GDSCript.

GDScript is not Python, so this argument is not applicable. Also, it would be better if Python used tabs too 🙃

3. The width of a tab is not standardised, while one space is always 1 character long, which makes its use more intuitive.

@fcole90 I invite you to read this post, and the comments: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/

The ability for tabs to have different widths is a serious accessibility feature, and the prevalence of spaces makes coding less accessible for people with visual impairments.

It's silly to use spaces and therefore force a specific indentation width on people when there are just so many downsides to it. Spaces take up more disk space, give users less freedom, and it's more complicated to determine how many spaces are equivalent to one level of indentation in a file. Tabs take up less space, semantically mean "one level of indentation" always, and give users more freedom. Spaces are more cumbersome to work with, I can't tell you how many times I've used a language with spaces and clicked in the middle of an indentation level by accident, or how many times I've deleted indentation from the left using the "Delete" key and had this be vastly easier with tabs.

The only reason I would choose spaces is if existing tools for the language enforced them, because it's counter-productive to spend time fighting with formatting tools. With GDScript, we have a clean slate and can choose the superior option (tabs).

[dalexeev]

3. The width of a tab is not standardised, while one space is always 1 character long, which makes its use more intuitive.

This is the only advantage of spaces, which is also a disadvantage. In fact, space users carefully emulate the behavior of tabs when pressing Tab and Backspace. So I also see no reason to change something in this situation.

The main argument would be that almost all modern style guides have settled on spaces over tabs.

I don’t think this is important if spaces don't have any significant advantages over tabs, and tabs don't have any significant disadvantages over spaces. I think this is the case, when the majority is wrong. Or these recommendations are outdated, since now almost any text editor and IDE allows you to customize this behavior, including locally for the project (.editorconfig file).

[Jummit]

Seeing the ratio of up/downvotes on this post I think it's very unlikely that the proposed change will be implemented. I suggest closing this proposal and letting the author decide if he wants to create another proposal which he thinks will get more approval.

[fcole90]

You're presenting many good reasons in favour of tabs, in particular about the accessibility issue. If you want to close the proposal, I'm fine with that 😊 👍

[Calinou]

Closing per @fcole90's comment.