Live data from Hacker News

Swift Style Guide by GitHub

github.com

31–40 of 52 posts

Re: Swift Style Guide by GitHub

#31

What does Github write that uses Swift? I thought they didn't have an iOS app and I figured their desktop app was some node-webkit or electron based thing based on it being 27mb download.

Swift is on track to be a general purpose language not only targeted towards iOS, OSX, tvOS, and Watch. There are already web servers written in Swift[1] so using Swift for backend work is increasingly more viable. They may have internal plans to implement some new products in Swift, but who knows.

[1] - https://github.com/izqui/Taylor

Re: Swift Style Guide by GitHub

#32

Earlier quoted context omitted.

Tabs beat spaces in every single way; - only press a single key instead of tapping 2 or 4 times. - alter their width within your IDE to suit your preferences. - they are "designed" to intent a piece of text with unlike spaces which are "designed" to break words. But use whatever you like as long as it's consistent :)

> But use whatever you like as long as it's consistent I would add "as long it's consistent with the codebase and the practices of the project" Mixing tabs and spaces in a project is very unpleasant and changing one for the other wreaks havoc in the blame functionality

    git blame -w …

Re: Swift Style Guide by GitHub

#34
The thing that strikes me is how much shorter a Swift style guide is, compared to an Objective C one. E.g. https://github.com/raywenderlich/objective-c-style-guide

This fact tells a lot about the langage. The language is pretty strict as to what it allows to write and reduces the need of a style guide to specifying best practices.

Re: Swift Style Guide by GitHub

#35
post #2

Lost me at "Tabs, not spaces." :p

Tabs beat spaces in every single way; - only press a single key instead of tapping 2 or 4 times. - alter their width within your IDE to suit your preferences. - they are "designed" to intent a piece of text with unlike spaces which are "designed" to break words. But use whatever you like as long as it's consistent :)

Ah, tabs are bad, because if you let people choose their own tab widths then it becomes impossible to align anything anymore. It makes it impossible to align anything which is != a tab width.

Tabs aren't "designed" for indenting text: they're a hangover from typewriters, where they were literally metal tabs used for creating tables. Tabs don't carry semantics - that's the job of the language's syntax. Tabs as a concept should be confined to history IMHO, especially their implementation in modern word processors, where they just give you ad-hoc semantic-less tables.

The tab key on the otherhand is great for indenting - in most sensible editors it will insert a configurable number of spaces. Perfect.

Re: Swift Style Guide by GitHub

#36
post #24
post #18

Earlier quoted context omitted.

If your editor doesn't do smart tabbing, I'm sorry for you. Not to mention that random trailing whitespace is just annoying.

Part of the problem is that Xcode (you know, the editor pretty much everybody will be using to write Swift) leaves blank lines indented. So to leave a blank line that doesn't have indentation, you press Return, and you get an indented blank line; you then need to press Backspace some appropriate number of times to get the cursor back to column 0; then you press Return. (In Xcode's defence, the cursor is, then, at lea…

It might help you to use the OSX keyboard shortcut cmd + shift + [left, delete]. The left variant will move you to the beginning of a line, delete will clear all preceding characters and put the cursor on column 0.

Re: Swift Style Guide by GitHub

#37
post #13

Earlier quoted context omitted.

Sounds to me like you're saying there's no objectively correct answer that works for all languages and situations, which I agree with.

There... is, actually. If you don't actually attempt to align the variable names, then what you're doing is "indenting items in a list", essentially. In general, you should avoid aligning unless the readability gains are significant. Aligning things means that you end up re-aligning when you add or remove longer items. This increases maintenance and pollutes diffs (which also means code reviews and git logs).

My editor aligns things for me - no effort at all.

Re: Swift Style Guide by GitHub

#38
post #2

Lost me at "Tabs, not spaces." :p

Tabs beat spaces in every single way; - only press a single key instead of tapping 2 or 4 times. - alter their width within your IDE to suit your preferences. - they are "designed" to intent a piece of text with unlike spaces which are "designed" to break words. But use whatever you like as long as it's consistent :)

I agree, particularly with Elastic Tabstops

http://nickgravgaard.com/elastic-tabstops/

Re: Swift Style Guide by GitHub

#39

Earlier quoted context omitted.

Tabs beat spaces in every single way; - only press a single key instead of tapping 2 or 4 times. - alter their width within your IDE to suit your preferences. - they are "designed" to intent a piece of text with unlike spaces which are "designed" to break words. But use whatever you like as long as it's consistent :)

Ah, tabs are bad, because if you let people choose their own tab widths then it becomes impossible to align anything anymore. It makes it impossible to align anything which is != a tab width. Tabs aren't "designed" for indenting text: they're a hangover from typewriters, where they were literally metal tabs used for creating tables. Tabs don't carry semantics - that's the job of the language's syntax. Tabs as a conce…

There is an easy solution to the alignment problem: don't align stuff.

I haven't used column alignment in at least 20 years. I don't miss it at all, and I'll never go back to aligning things.

Column alignment causes far too many problems. Once you give it up, any advantage of spaces over tabs disappears. Code written without alignment reads the same whatever you use for indentation, and it is even perfectly readable in a proportional font!

I've written a few comments on HN about the problems with column alignment and the advantages of an alignment-free style. Here are a couple of previous discussions with specific examples:

https://news.ycombinator.com/item?id=10206860

https://news.ycombinator.com/item?id=9469713

Re: Swift Style Guide by GitHub

#40
post #17

> Not even leading indentation on blank lines. Ugh. I wonder how is this a real issue? Non-indented blank lines ARE an issue though - they make code editing more cumbersome, requiring pressing the tab key far more often. Also, tabs are for bros.

I'm on Xvim so I'd prefer to have non-indented blank lines for navigation with { and }. But I wouldn't suggest this guideline for projects where multiple devs since Xcode defaults to indenting blank lines. IMO you want to set yourself up for success as far as consistency goes, and that means sticking to defaults where possible.
Post reply on HN