> On Jun 24, 2016, at 9:33 PM, Xiaodi Wu <[email protected]> wrote: > > On Fri, Jun 24, 2016 at 2:26 PM, Charlie Monroe <[email protected] > <mailto:[email protected]>> wrote: > >> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber <[email protected] >> <mailto:[email protected]>> wrote: >> > On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <[email protected] >> > <mailto:[email protected]>> wrote: >> > On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <[email protected] >> > <mailto:[email protected]>> wrote: >> >> >> >> Not a practitioner of 80-character line limits, I take it? >> > >> > I don’t understand why anyone wouldn’t just let Xcode do the wrapping for >> > most cases. I’ll add newlines if I think it adds to clarity, but in >> > general I don’t want to code like i’m still on a Wyse WY-50. >> > >> > Of course, to each their own style--I certainly wouldn't want Swift to >> > force everyone to write lines of certain lengths. But 80-character lines >> > is a common style, and I would say that a corollary of "to each their own" >> > is that Swift's grammar should be usable and useful whether or not you >> > adhere to such style choices. >> >> I honestly don’t believe that this a common style in the Cocoa community. >> >> We're talking about the Swift community here, and Swift stdlib would be a >> good starting point as to what is a common or at least accepted style; it >> uses 80-character lines. > > While it does, it makes sense only for readability purposes of the > documentation. For example, I see absolute no reason why to split > https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233 > > <https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233> > into two lines. > > It makes the code less readable. > > 80-char style made sense in C, where everything is pretty much top-level. But > given that you declare a class, within which you declare another class, > within which you declare methods, the first level of the method indentation > is at level 3, which given 4 spaces per tab gives you 12 characters already. > Adding a few levels (for-cycle + an if statement within the for cycle) gives > you 20 characters of just whitespace (1/4 of the allocated 80 chars per line). > > Which is why I don't believe this code style is valid in a modern language. > > This is one style that some very intelligent people use in Swift. I'm not > going to debate what styles are "valid."
I'm sorry, if this sounded offensive in any way, I certainly did not mean it that way, I simply wanted to point out why I believe the 80-char limit is a bit limiting nowadays given that you can nest various constructs. > My personal guess is that it should be upped to e.g. 160 chars per line - > that kind of makes sense. There is no particular reason other than historic > why we're still using 80 chars per line. > >> >> I’m not a member of the “old guard” having only come into this world 10 >> years ago with the iPhone, but just take a look at this delegate method in >> Objective-C: >> >> - (void)locationManager:(CLLocationManager *)manager >> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError >> *)error; >> >> That’s well over 80 characters all by itself. This fits on my screen in a >> single line - and I work on a 15” MBP with room for my dock always visible >> on the side along with Xcode’s sidebar open! On a typical desktop-sized >> screen, 80-col lines must be comically short. >> >> I don’t know why it should be assumed that people are adhering to a >> so-called standard that dates back to terminal screens that didn’t have >> color. >> >> >> > If the chief advantage of `where` is that it (quoting someone above) >> > allows one to "understand as much as possible about the control flow of >> > the loop from a single line of code," then we ought perhaps to question >> > its appropriateness when the majority of its benefits [by which I mean, >> > based on your examples and Sean's, more than half of the instances in >> > which it is used] cannot be realized in a very common coding style. >> >> Again, I dispute the idea (having no data but my own :P) that 80-col limits >> are common in this community. >> >> l8r >> Sean >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
