[swift-evolution] Source Formatting

[Paul Ossenbruggen]

Actually, I think this is a cool idea and I had thought along these lines too actually years ago of saving in an intermediate format. The difference that I am thinking now is that there is a Swift standard format. Where the “standard” format is what is written, but the IDE displays it in the users’ favorite format. This would not lead to diffing problems since it would be stored in Swift standard format that everyone can read and would readable and editable any text editor. So the standard might have braces at the end of the line, but when you open it in your IDE it will put them in your preferred aligned position, when it is saved, it goes back to standard format. I would not be surprised if something like this existed already (not specifically for Swift) Coming up with the standard format would largely be following most of the sample code in the Swift book so it would not be annoying to read. Just when you are hard at work on your code, you can have your favorite “view” on your code. If this component were shared it could be added to any IDE, in its read and write functions. 

One tricky aspect is keeping reasonable spacing between lines. This would need to be saved in the standard format, Someone who likes things crammed together would not add spacing and their view could remove it from display, but it would do its best to preserve it in the standard file format. However if it is never inserted by the person who likes tight spacing, another person might add it in for their benefit. The tight spacing person would not see the extra lines but the standard format would keep them in there if they did not change those lines. If they did change those lines it would do its best to preserve those spaces. 

Maybe a bit wacky but seems at least possible. 

- Paul


> On Mar 12, 2016, at 6:05 PM, davesweeris at mac.com wrote:
> 
> I’m not claiming that what follows is a *good* idea per se, just that it solves the problem Ted brought up…
> 
> What about adding an option for saving source code in a pre-parsed representation so that the displayed coding style can be decoupled from the actual source code? Off the top of my head, I think a stringified AST would work (or at least something very close to that). Is this overkill? Yes. Yes, it is. But it’d forever end the debate over which coding style the team should use... Each person could configure their IDE however they want, and it wouldn’t affect anyone else because this:
> func foo() -> Int {
>     let bar: Int = 0
>     let longBar: Double = 0
>     return bar + Int(longBar)
> }
> vs
> func foo() -> Int
> {
>     let bar:    Int     = 0
>     let longBar:Double  = 0
>     return bar + Int(longBar)
> }
> vs
> func foo
> () -> Int
> {
> 	// Everything lined up using “proper" tabs instead of spaces
> 	let bar:	Int	= 0
> 	let longBar:	Double	= 0
> 	return bar + Int(longBar)
> }
> vs even this Python-esque insanity
> func
> foo
> ()
> Int
>     let bar: Int = 0
>     let longBar: Double = 0
>     return bar + Int(longBar)
> 
> would all strictly be a local display preference, the same as your choice of font or monitor resolution.
> 
> As long as the format is human-readable, people could still use straight text editors if they needed to edit code that’s in this “pre-parsed” format if there isn’t a “.swift.pp”-aware editor available for their platform.
> 
> 
> 
> Anyway, that’s all I’ve got for this one. Pretty sure it’s too far out there, but posting it anyway just in case I’m wrong.
> 
> - Dave Sweeris
> 
>> On Mar 11, 2016, at 4:19 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> In most IDE, like Eclipse, Netbeans etc. the formatting
>> is done by the IDE., It is NOT part the programming language *
>> 
>> The programmer has the option to customize how
>> the IDE should format the source. Mostly one
>> will adjust this as much as possible conforming
>> with the company standard way of working.
>> But there are exceptions: more about this further down
>> this text.
>> 
>> Formatting should not be part of the programming language itself,
>> except of course for obvious things, like unintentionally “glueing”
>> language elements together, which, of course, result
>> in compilation errors.
>> 
>> Also, there will always be sloppy programmers,
>> no matter how good formatting could perhaps be,
>> people will always find ways to create a fantastic mess.
>> but to accept this or not is the responsibility of the team 
>> he/she is in.   
>> 
>> So, Xcode, or for that matter any other IDE you might use, 
>> should have under “Preferences” the option to customize 
>> formatting behavior and also the option to disable formatting altogether .
>> Luckily, most IDEs provide this customization already. 
>> Why? 
>> Because no two humans are the same.
>> 
>> Even more Important: dyslexia disorder,
>> which is:  **
>>    " a general term for disorders that involve difficulty in learning to read 
>>       or interpret words, letters,  and other symbols, 
>>      but that do not affect general intelligence.”   
>>     "It is estimated that between 5-10% of the population has dyslexia, 
>>       but this number can also be as high as 17%.”
>> 
>> Dyslexia is nearly always present in combination with autism.
>> As you know, many programmers are more or less autistic. 
>> Probably even more of them than in the average population. 
>> 
>> Forcing default formatting upon them (a lot of us) is obviously not a good idea! 
>> 
>> There are endless debates e.g. about using { }  
>> 1.  
>>    func foo() {
>>  	 a = b
>>     }
>> 
>> or  2.      
>> 
>>    func foo()
>>    {
>>        a = b
>>    }
>> 
>> Personally I prefer 2. because
>> if I navigate through my source very quickly
>> my eyes don’t have to go to the end of each line
>> to find a starting { 
>> resulting, at least for me, in much faster editing. 
>> I am not very good with trailing tokens. 
>> 
>> also I prefer to align variables like this
>> var  a:            Double
>> var  boat:       Boat
>> var  weather: ClimateOption
>> etc.
>> 
>> Because I find that much easier to read
>> maybe autistic aspects of me.
>> (which btw also make communicating with other humans a bit difficult for me, you might have noticed that)
>> The strange thing is that, if formatted the way I prefer it,
>> I can read sources very fast..
>> 
>> So, formatting should definitely not be
>> be part of the programming language
>> which is in essence free-format, luckily.
>> 
>> Another note in this perspective is:
>> One should not treat programmers like little children
>> that need to be (over?)protected from themselves.
>> 
>> One can safely assume, that, if one has made 
>> it in being a good programmer, one obviously 
>> possesses a reasonable intelligence level.
>> 
>> 
>> TedvG
>> 
>> * (except perhaps for Python, albeit that the only requirement
>> with Python is indentation)
>> ** source: Wikipedia
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160312/9f7c1207/attachment.html>