Tabs, Spaces, and Scripting

One of the most common scripting issues I see here and in other python forums is mixed whitespace characters. I prefer spaces myself but won't fault anyone for choosing tabs. It appears to me that the devs also prefer spaces, most of the examples in the docs use spaces for indents. However the script editor uses tabs.
This wouldn't be a huge issue for me, I'm comfortable using an external text editor like notepad++ which lets you replace tabs with spaces. But using an external editor is painful due to the auto-indent incorrectly indenting.
Am I missing a simple solution?

Huh??? If you want to use spaces, just use spaces?

I have never had an issue using spaces in the script editor or the script console as long as I always use spaces through out the script.

Personally, I prefer Tab's because it's few key strokes, and it's easier to determine by looking if your indentation is off.

4 Likes

They're referring to the script editor not letting you add 4 spaces when you press tab (a setting on almost any IDE).

2 Likes

Like @Troy said. If you need to indent a block of existing code, using spaces in the script editor will make you want to pull your hair out since you would need to manually add the spaces to each line of code you are trying to indent. Or get in the habit of first cutting the block of code, typing in the 4 spaces, and then pasting - it will then put in the spaces for each line...but who would ever want to do that :sweat_smile:

Edit: I was trying to recall where I ran into an even bigger headache with spaces and then remembered it was with Custom Methods in Vision. The auto generated doc-string uses tabs and there is no way to change them to spaces that I am aware of. So when you try to add lines below with spaces, it will give you an IndentationError that can only be fixed by switching to tabs. The example code in the Extension Functions also use tabs which a lot of people don't realize when they uncomment the code. Power Table example:

In other words, just use tabs.

4 Likes

Agreed. I just wanted to make sure others know that there are roadblocks to using spaces in certain parts of Ignition that throw the personal preference discussion out the window.

Edit: btw, I just noticed the cake icon, happy forum anniversary @pturmel!

5 Likes

Huh, thanks for the clarification.

I have never had the need/desire to look for an option like that. I have always used tabs, to me white space is white space (to the eye, Iā€™m aware there is a difference).

The only exception is when writing code directly in a forum post, since the browser steals the tab key event and moves focus. Otherwise, I just hit the tab key and I get whatI get.

5 Likes

I am a tab user so that I can say I am a few hundred percent more efficient at coding than my space using coworkers.

6 Likes

If you have ever listened to the Oxide Computer podcast On The Metal, they mention tabs versus spaces in an episode. The person they interviewed said that tabs were preferred during a certain era due to a situation where a tab was faster and used less transfer data then multiple spaces. Pretty interesting. I'm a tab guy myself.

2 Likes

I'm personally in favor of relaxing this behavior, but it's a backwards compatibility nightmare, surprisingly. For now, I'll echo the sentiment in this thread: just use tabs.

The decision to supply a fixed header and function comment for extension functions is the root cause. Stop doing that. Supply it as a convenience, but don't force it. Just check that the def something(...): is unchanged before accepting an edit.

That would make cut-and-paste nicer, and should allow all prior serialized forms to work.

3 Likes

We already have stopped doing it, in Perspective and everywhere else 'modern'. The problem is everything else in the system.
Vision, in different areas, serializes either A: the user's script, B: the user's script plus the def line, or C: the user's script, the def line, and the docstring comment. Some of those areas do and don't count that docstring in the line number for errors, as well. Changing how things are serialized back down without bumping resource versions required some shenanigans; e.g. right now if you copy a Vision component from a post-script-editor-rework version to a pre-script-editor-rework version, it will compile, but the docstring will be missing and it'll have a big warning instead.

Hmm. I only ever noticed "C" when digging around. ):

A missing or different docstring should be tolerated.

In my search for some comedic relief this week, I encountered the following comic and remembered this conversation:

For the record: (I prefer tabs)

I can't stand spaces! Why would you tap 3 times instead of once?

I'm fine with spaces if I don't have to type them. Which is almost never, so, tabs it is.

I've been wondering that for a long time. Why the hell would PEP8 recommend using spaces ?

IDEs give you the option to replace the tab key with 3 spaces. Its the same keyboard input.

1 Like

Backspace, I believe, still only back spaces one space at a time though so you have to backspace 3 times unless you use shift tab. But still, copying the code to other places you'll have to use backspace most of the time. I can't think of anything worse