[swift-evolution] Source Formatting

Paul Ossenbruggen possen at gmail.com
Sat Mar 12 01:26:44 CST 2016


I am not suggesting that everything be specified, but code is read more often that written. Not allowing a mixture of styles in the same file or line, like if you put spaces after commas it should enforce that for the rest of the parameters in the function. Make it easier to follow good practices than not. So the IDE could help out by noticing that the first parameter had a space, similar to how it automatically inserts a matching brace when or reinvents when you end a line, and automatically add a space. I see a lot of really awful looking code out there in other languages. I would like to see some basic formatting enforced as it does around the x == y case and spaces before braces, but nobody is ever going to agree whether braces go at end or beginning of the line, but it could be enforced by keeping it consistent within a file. If people could look at a swift files and it always looked pretty good, they may be more interested in learning more about the language. 

If that is not possible, perhaps it should be a set of coding style guidelines that like the function naming document is best practice but not required. 

The point about everybody is different and should do whatever makes them happy, I am not sure i agree with though. We have standards for writing English which most people adhere to. There are debates about two spaces after a period, but most people are ok so long as it is consistent. Spanish has slightly different standards. It makes easier for everyone to read than if everyone does their own thing. 


> On Mar 11, 2016, at 2:19 PM, Ted F.A. van Gaalen <tedvgiosdev at gmail.com> 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
> 



More information about the swift-evolution mailing list