> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber <s...@fifthace.com > <mailto:s...@fifthace.com>> wrote: > > On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <w...@mac.com > > <mailto:w...@mac.com>> wrote: > > On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <xiaodi...@gmail.com > > <mailto:xiaodi...@gmail.com>> 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. 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
