Godot-proposals: Spaces shouldn't be converted to tabs when used for alignment

[aaronfranke]

Describe the project you are working on:

This applies to any project which has code aligned.

Describe the problem or limitation you are having in your project:

The problem is that Godot automatically converts four spaces into tabs, regardlesss of where they are. Tabs should be used for indentation, but they should not be used for alignment, since the alignment breaks when the tab size changes.

This code:

    emit("pinch", InputEventScreenPinch.new({"position":event.position,
                                             "distance":200.0,
                                             "relative":-40.0,
                                             "speed"   :25.0}))

Currently gets converted into this when saving the file:

    emit("pinch", InputEventScreenPinch.new({"position":event.position,
                                             "distance":200.0,
                                             "relative":-40.0,
                                             "speed"   :25.0}))

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

The proposal is to not do this when spaces are used for alignment. In particular, in the above code, you can see that the emit statement does not end until the last line. This means that everything inside of this should not be converted. Spaces should be converted to tabs when used for indentation, which means always convert outside of statements, but not inside of them.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

The non-bolded parts are what the existing logic looks like, the bold is additions.

Look for 4 spaces. If spaces are inside a statement, do nothing. Else, convert to tabs.

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

No.

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

This can't be an add-on, it's part of the script editor.

[Xrayez]

I have to agree, the enforcement of either tab or spaces has lead to breaking existing style conventions regarding code alignment, for instance see bitwes/Gut#126, and the actual style change made by Gut creator.

[pycbouh]

I guess nothing short of JetBrains' extensive setting list for code style will make everybody happy. However, personally, I don't think that spaces should be used for alignment, if they are preceded by tabs. This block of code has always been problematic:

    emit("pinch", InputEventScreenPinch.new({"position":event.position,
                                             "distance":200.0,
                                             "relative":-40.0,
                                             "speed"   :25.0}))

You used spaces to pad lines after the first tab, but some may use tabs all the way, until they only need a space or two to adjust it. And then it is only aligned as long as everyone on your team uses the same size for tabs. Plus, this code style can result in bad diffs in your VCS. Both problems go away, if you format it like this:

    emit("pinch", InputEventScreenPinch.new({
        "position":event.position,
        "distance":200.0,
        "relative":-40.0,
        "speed"   :25.0,
    }))

That said, I am not supporting any code style enforcement. Coders are creative and passionate people and love their tools to be fine tuned for their personal style. So, if possible, I'd prefer this to be an option, not a hard rule one way or the other.

[aaronfranke]

@pycbouh You're right, the code you posted looks much better. Since I think it's better to use that anyway, I don't really have an immediate use for this proposal, but spaces are still ideal for alignment due to consistency - tabs are for indentation.

And then it is only aligned as long as everyone on your team uses the same size for tabs.

The thing is, the configurability of tabs is a blessing, even if it has downsides. We should not require people to have the same tab size in order to have good looking code.

[pycbouh]

The thing is, the configurability of tabs is a blessing, even if it has downsides. We should not require people to have the same tab size in order to have good looking code.

Yes, which is why I don't like mix'n'matching tabs and spaces. Spaces are always uniform, tabs are set up to personal preference. Whatever one team prefers, having it both ways only brings confusion, in my opinion.

[Kequc]

I don't want to start a debate about spaces or tabs but you almost certainly shouldn't be using both for alignment. One of the core benefits of tabs is easy alignment. Using spaces and tabs for alignment is a mess.

[aaronfranke]

@Kequc No, tabs are for indentation, not alignment. Tabs mean "I want to indent this one level" and the editor determines how big that is. Spaces mean "I want to align by X characters exactly".

[Kequc]

I think you'll find that this isn't the only thing that the godot engine discourages you from doing. I don't agree with all the decisions made but if we're going to start promoting any code style or way of doing things the engine could end up bloated.

Feel like cutting off my comments there to, again, avoid getting into a spaces vs tabs debate which is always what these turn into.

[aaronfranke]

I'm closing this because I no longer see this kind of alignment as a good thing. If you care about things lining up, it's best to make the first item on the next line, as @pycbouh demonstrates in this comment. Therefore, there is no purpose to allowing spaces for alignment.