Oh no, hurry!! switch of your screens!!
Hide under your desks!!
The SourcePolice-- has arrived!!! :o)
Imho people should be free to format and style their source in any way
they like -apart from company and team enforced standards when
working for or with them, of course.
For example, You might have noticed on this forum, e.g. that I always
put brackets on a new line, because I find it much easier to read.
(not doing so, I personally consider this as a traditional bad habit,
taken over from C and C++, being useful only in long gone days of limited
screen estate, when printing out sources was often the only way to have a
good impression. Or in digital medieval times, It saved a lot of weight (literaly)
when I still had to edit with punched cards as source carrier, as each card
could only contain 1 line.)
Xcode respects largely personal preferences and e.g. in Eclipse, Netbeans
one can set one's own formatting preferences. However, for instance, the
Dart-language-people, in al their unlimited wisdom, found it necessary to
enforce a formatting dictatorship. You can't customize source formatting.
What they enforce is in their vision the only perfect way. Silly.
So, it you want to write code like ( fasten seatbelts, please)
if a>b {c = b}else{c=a;swap(a,b);arrgh(arrghument)} // etc.
That's ok with me.. as long as I don't have to maintain your code.
The only (formatting and other) standards one should, or rather, must
conform to are those necessary when working in a team, or e.g.
when contributing source entities to Swift open source.
And where is the end? you could even take this 1984 style dictatorship
much further, e.g. by not allowing identifier names to be < 3 characters etc.
(or removing certain unstylish source elements, but that's another matter, is it not?)
I'd say, it is rather a matter of commonSense++.
I've worked long ago in a Cobol team where it was not allowed to
start an if block with a "not" like so (in Swift):
if ( ! someFunc(value)
{
spanishInquisition()
}
we then had to write it like so:
if someFunc(value)
{
}
else
{
spanishInquisition()
}
Because that was the company's way of doing things,
stemming from the endless wisdom of the local gods,
?
(sorry CommaConfusion (wow, that's a really cool name for a band!))
people that worked there for twenty years or so,
without noticing that there is a world outside their fences...
but perhaps it also has to do with the fact that,
at least for building my own apps++, I've metamorphosed
into being an Indie Developer, and some aspects of
that are very cool, like not loosing 50% of my time
(although having plenty of it) for team coordination.
The luxury of doing things, at least in this domain,
the way I prefer.
TedvG.
···
On 10 Mar 2016, at 09:09, Radek Pietruszewski <radexpl@gmail.com> wrote:
This is a linter's job.
Sent from my iPad
On 10 Mar 2016, at 05:28, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:
Most people are good about it but there is always one or two who take advantage of something like this, and if you allow it they will. I think it would drive me crazy to see this:
let person = Person( id: json['id’], name: json['name’], picture: Im2age(picture), friends: friends,)
This would drive the anally retentive people crazy! I mean Swift was great that it got rid of the braces here:
if x == y {
} else {
}
so no more running the parenthesis right up against the if. But someone I know does this now:
if x == y{
}else{
}
Arrrgh!
Can we force the space before and after the paren? Without requiring uncrustify? :-)
On Mar 9, 2016, at 12:47 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 9, 2016, at 2:34 PM, Grant Paul <grp@fb.com> wrote:
Thanks for the feedback everyone! A few more notes to add to the proposal:
- Rust also supports trailing commas in argument lists and tuples.
- Alternative proposals suggested by Haravikk:
1. Support trailing commas only in multi-line argument and tuple declarations. This is an interesting approach, and would codify good practice in the language. It might make the most sense for a lint-style tool. On the other hand, in Swift, the choice of whitespace character is usually not significant. Putting this rule in the language would change that for only a small benefit.
2. Allowing trailing commas except when it could cause ambiguity; for example, with type inference, overloading, or default parameters. This seems like the most complete way to prevent mistakes, but it also seems like it might be difficult to implement if the allowed syntax changed based on the type checker. Would have to defer to people with more experience in the Swift compiler if this is feasible.
Nisse —
Echoing what Radek said, the JavaScript “comma first” style comes directly from a *lack* of support for trailing commas (in Internet Explorer specifically). That style appears to have been first suggested here: A better coding convention for lists and object literals in JavaScript · GitHub — part of the rationale was "a final trailing comma will cause errors in MSIE”.
Patrick and Ted —
Do you also see the same issue with incomplete thoughts when writing arrays or dictionaries, where Swift does currently support trailing commas? I think that case would be more likely than in argument lists: an incomplete argument list would fail to compile in most cases from an incorrect number of parameters, but an incomplete dictionary or array would necessarily still compile.
Absolutely.
I work on a geographically diverse team, which demands an interrupt-driven environment. Dealing with phone calls, emails, and IMs must take priority to maintain communication between team members. Sometimes those interrupts deal with code. Thus, if I'm coding a call site or an array/dictionary initialization site when an interrupt comes in, it is likely that I don't switch back to the context, leaving some incomplete code. I'm sure if I put my head to it, I could think of other places allowing trailing commands are going to hurt me more than help me.
It could be a reasonable proposal to disallow trailing commas in all places, albeit one I would disagree with.
Grant
On Mar 9, 2016, at 10:55, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
I have to agree with Ted. When I leave a "trailing comma", it's almost always because I constructing a call and didn't finish, for whatever reason. Thankfully, the compiler is nice enough to tell me when I committed this error.
Cheers,
-Patrick
On Mar 9, 2016, at 9:44 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:
Hi Paul
I don’t think that is a good idea because:
as in most human languages writing,
the comma tells us,
that more is following,
?
?
.. oops. hey, no more text?
So, to me your examples are incomplete statements,
leading to mistakes when editing, me assuming that I
didn’t finish typing the statement, when I started
editing the source say, three months later.
or, doing maintenance and having to fast-read through
many old source files.
Is it really so hard to press the DEL key to remove
the trailing comma?
Greetings,
TedvG ,
(sorry no more text here :0)
Right now, Swift argument lists are not permitted to contain trailing commas. To make multi-line calls easier, we propose allowing trailing commas in argument (and tuple) syntax:
let person = Person(
id: json['id'],
name: json['name'],
picture: Im2age(picture),
friends: friends,
)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=TiMad4REPS_rpOXRZiQytQ&m=5hE4Yb04I38N2u3hF1YNWi2rnd6td7WW3_sIMgH1UHU&s=QncXBAO3MI-M5GEJ-wFM9qPqCReaGIzogre9d5EubAE&e=
_______________________________________________
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