[swift-evolution] Source Formatting

[Ted F.A. van Gaalen]

Hi Paul, thanks for you nuanced reply, giving a better view on the matter.
I do agree on most points.
> On 12.03.2016, at 08:26, Paul Ossenbruggen <possen at gmail.com> wrote:
> 
> 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.
Yes.

> I see a lot of really awful looking code out there in other languages.
not much has changed.. would you like to see my first Fortran sources from 1979? Spaghetti, 
was a rookie back then :o)
I think btw that this is also because software developers are often
on too tight deadlines, writing under stress 
then as we all know formatting/styling/commenting is unfortunately neglected

> 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.
One can specify these spacing option in the IDE, again I don’t think this should be done by the Swift compiler


> 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. 
> 
Of course! But is also looks much more readable due to the clear nature of Swift.

When I look and C++ sources, they look often horrible, I have tried to avoid C, C++
and also Javascript as much as possible during my life. 

> 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. 
I think coding style etc, should be defined by the company/project one is assigned to. 
(e.g. by defining the proper program templates/standards, also for the IDE fornatting. 
And also e.g. if you deliver source code to the Swift open source a uniform approach is of course desirable. 
> 
> The point about everybody is different and should do whatever makes them happy, I am not sure i agree with though.
E.g. I build my apps alone, so no one else is involved, so working the way I want doesn’t affect others. 
Here, I don’t even use a version system like Git, too much overhead, just backing up each day. 
In this situation I prefer tools that do not restrict me.  

> 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. 
But these standards are luckily not enforced.  
If it was so strict then I my German writing would
often be rejected because of grammar etc. 
being a Dutchman here in Germany :o) 
> 
TedvG

> 
>> 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
>> 
>