Swift's SWITCH indenting is driving me mad... any way to fix this?!

So I'm getting really annoyed and I don't know if it's Swift that's the problem or Xcode's code layout system...

I need to write switch statements like this:

switch Int
{
    case 0:
        do something

    case 1:
        do something else
}

But what I always get is this:

switch Int
{
case 0:
    do something

case 1:
    do something else
}

Where the case is inline with the framing switch statement... which is just...wrong... ugly, confusing and really annoying.

Does anyone have a fix?

4 Likes

Backing the cases to the same indentation level as the "switch" is a common style for all C-inspired languages. Said languages also don't officially care what the actual spacing is. If you don't like the style, the problem is in Xcode's code layout, not Swift. I don't know how to override it (besides manually), though.

2 Likes

Yep, Xcode 11 ships with a preference for it under "Text Editing":

13 Likes

Cases are part of the switch statement, therefore is their indentation different from what you may be familiar with from other languages.

Also please don‘t write your posts and title in such a heated manner, this is inappropriate and discourages people to join the conversation.

11 Likes

Thank you, you're my hero.

Now just have to wait for Catalina. :/

Cases are part of, but belong TO the Switch statement, they're not of the same level / priority... they are internal to the Switch statement, therefore they shouldn't be visibly on the same level of indentation as the Switch statement.

And I come C, C++ and Obj-C. This never happened there.

Why does my frustration bother you so much? At least others here were very helpful.

2 Likes

I don’t think anyone is bothered by your frustration, but rather how you chose to express your frustration. Please keep a civil tone, and refrain from expressing opinion and preference as fact.

You’ll find that people are generally understanding of your point-of-view, even if they don’t share it, and will help you find a solution if you ask politely.

6 Likes

I get annoyed with it too when switching between languages but it's the default for Swift, so my unsolicited (:innocent:) advice would be to get used to it :man_shrugging:

3 Likes

This post was flagged by the community and is temporarily hidden.

No one is "gatekeeping" you from giving your opinion; in fact, you have people in this thread who are expressing their agreement with you about the formatting. Saying "Swift is awful" on top of that is baseless and nonconstructive.

Personally, I have never liked the accepted indentation style for switch statements in other C-ish languages; I like and prefer the less indented style that Swift uses, so I hope you don't believe that your opinion is objectively correct.

6 Likes

....

:face_with_raised_eyebrow:

Anyway you're making objective statements about something that's an opinion on style. Some people indent Swift with 2 spaces which looks gross to me. That doesn't mean it's wrong.

One case for cases being at the same indentation would be that case statements aren't really code. it's more like multiple if statements, which are not indented. Especially with how often Switch can be used in Swift, it lessens the level of indentation for any enclosed code, which helps to prevent as many pyramids of doom.

5 Likes

Anyway you're making objective statements about something that's an
opinion on style. Some people indent Swift with 2 spaces which looks
gross to me. That doesn't mean it's wrong.

It seems to me that by increasing indentation from 2 spaces, many
program fragments should become more readable for most developers. You
could state some testable hypothesis about indentation width and then
perform user studies that, if they replicate, give us some objective
grounds for deciding these "style" questions.

One case for cases being at the same indentation would be that
case statements aren't really code. it's more like multiple if
statements, which are not indented. Especially with how often
Switch can be used in Swift, it lessens the level of indentation for
any enclosed code, which helps to prevent as many pyramids of doom.

(I have not seen the expression "pyramids of doom" before. I like
that!)

Incidentally, I think there is a case to be made that "shortening
staircases," exiting early, and putting the opening curly brace onto the
same line as the if, while, for, or switch keyword should not be
left up to individual opinion.

I don't say this to rile anybody up, I just want to suggest that there's
another way to think about these issues.

Dave

I would be curious as to your rationale for not allowing individual opinion.

This is all rather irrelevant, as this functionality comes from Xcode’s automatic styling (which is controllable in Xcode 11), not Swift itself (aside from it also being the default style of Swift code). Now that swift-format is being integrated into the Swift language server, it’s likely that future tooling will be able to control this behavior.

im annoyed by this too, especially since atom doesn’t know how to collapse the switch statements if the cases are all at the same indentation level. maybe this is just bad tooling though.

1 Like

Hopefully LSP will fix that for most other text editors.

Collapsing is already implemented in SourceKit-LSP, but it doesn't collapse switch statements as far as I can tell

speaking of that, where are we on the swift lsp anyway?

Try AppCode. It lets you set up formatting for just about anything. It works with Xcode, but is an amazing code editor and its ability to search through code is great. Another great tool from JetBrains. And no, I do not work for them.

Alright, well, I'm going to gate-keep you from expressing your opinions, at least like this. You're well within your rights to dislike Xcode's default code formatting, and talking about that is on-topic for these forums. But you've made two threads in your history posting here and both have rapidly devolved into defensiveness and invective, and we don't need that kind of contribution.

Closing the thread.

11 Likes
Terms of Service

Privacy Policy

Cookie Policy