Back to Blog
Xcode format code5/26/2023 A pushdown automaton for whitespace parsing With the new “Source Editor Command” extensions possible in Xcode 8, I wanted to see if I could produce something that enforces whitespace rules as I’d like them to be enforced in my own projects. It’s not open source so I can’t customize it to my personal preferences.It always marks the file as “dirty” so it’s difficult to tell what, if anything, changed.It can’t be run in a “pre-flight” mode to see if or what it would change.It only fixes indentation problems (not other whitespace issues).I often wonder why it isn’t run automatically over code created from templates or snippets to apply the user’s indentation preferences. Xcode does offer “Re-Indent” for correcting the indentation of your file (menu “Editor → Structure → Re-Indent”, or Ctrl-I, by default). You can run tools like SwiftLint to detect problems but you’re left to manually fix problems for yourself. Additionally, there’s always the possibility of typos inserting whitespace where it doesn’t belong or deleting whitespace you’d prefer to keep. ![]() If SourceKit crashes, Xcode will forget all your indentation preferences.īeyond indentation problems, there are different Swift community opinions about whether some : characters should have spaces on both sides or just the right side, about whether case labels should be indented, about whether #if contents should be indented and more. Copy and paste code and Xcode will reformat your neatly formatted code according to its own whims (unless you carefully paste and preserve formatting). Code snippets sometimes hard code indents. Xcode file templates hard code indentation, ignoring your project settings. Compose program state into fewer variablesĬode edited in Xcode is particularly prone to whitespace problems.A pushdown automaton for whitespace parsing.While this article continues to work (I continue to use it for my own whitespace reformatting), and is a good demonstration of Xcode Source Editor Command extensions, if you’re primarily looking to perform ad hoc parsing of Swift code, you might want to start with SwiftSyntax, rather than the parser in this article. NOTE: since this article was written, a better way of parsing Swift code, SwiftSyntax was released. Accordingly, most of this article is not really about Xcode Source Editor Command extensions or whitespace issues but is actually about design choices related to large, complex switch statements in Swift: choosing data types to switch upon, designing case patterns to handle a deep decision tree in a single switch statement, when to use custom pattern matching and when to use where clauses. The fun part of this exercise for me was writing a pushdown automaton parser where all of the parser logic was expressed through the case patterns of a single Swift switch statement. I wanted to see if an Xcode source extension could reduce my annoyance with this issue. ![]() It’s a topic I’ve touched on before because I’m frustrated by the continuous burden of correcting whitespace in my projects. The result is an extension that detects and corrects whitespace issues. ![]() ![]() I took a break from converting projects to Swift 3 this weekend and instead played around with writing a new “Source Editor Command” extension for Xcode 8.
0 Comments
Read More
Leave a Reply. |