> > • When I see a line in my own code that is hard to read because it is wider > than a typical editor, I take it as as sign that I should break it myself. I > also ask myself whether I’ve organized the logic properly. Maybe yes, maybe > no, but it’s a smell, like a 500-line function. That answers objections to > automatically wrapping code, that I can think of: It’s objectionable because > it doesn’t reflect your intentions. Formatting code so it reflects your > intentions is your problem. >
I generally agree that if a line gets too long it would either disappear off the end of the screen or be broken randomly then you should break it yourself. A great example is the code you see on the WWDC videos which is rendered in a gigantic font so it shows up and is so broken up by line wrap you can hardly read it. it would help a bit if Xcode’s default formatting when you hit return in the middle of a line didn’t put the fragment in some very odd places. I’ve broken lines before to have the start of the broken line only a few characters further left than it began. This is definitely a problem I’ve been having with Swift formatting. Xcode really wants a certain format and if you want to do things like put starting braces on new lines or indent switch/case statements in what I’d call a normal way, I find I’m fighting the editor quite often. It probably doesn’t help that I’ve adopted a possibly unusual formatting for closures because I was finding them hard to scan. My Pet Hate however is a very simple one. Xcode wants no spaces between an opening paren and the next character. I put spaces after my opening, and before my closing parens. I often find typing the space gives me a ghost paren which hovers there until it apparates and upsets the syntax checker. I don’t know how many of those things I’ve deleted in my life. I would dearly like some ‘this is how I format my code’ options I could set which the text editor would respect. Not every possible one, just the more usual ones, spaces after parens, opening braces on new lines, couple more. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
