Source Formatting

Evolution Discussion
1

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

2

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

3

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Hi Paul, thanks for you nuanced reply, giving a better view on the matter.
I do agree on most points.

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 12.03.2016, at 08:26, Paul Ossenbruggen <possen@gmail.com> wrote:

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

5

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

6

I also have had that kind of idea.

You can do something like this with git, iirc they're called filters.

Pierre

···

Le 13 mars 2016 à 03:45, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> a écrit :

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

7

C++ examples:

<Clang-Format Style Options — Clang 18.0.0git documentation;

Old demo (video):

<Shows | Microsoft Learn;

-- Ben

···

On 13 Mar 2016, at 02:45, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

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)