> it is annoying that the end of the list is always special. You can't just copy some line and move it there. Also when moving things around you always have to take extra care at the end.
You have simply moved the "special" entry to the beginning rather than the end.
Side remark: I've noticed that when it comes to code formatting and grammar it's almost like there are broadly two camps. There are some instances of code formatting that involve something "clever". Your example of leading commas above for example. Another example is code ligatures. It's as if there's a dividing line of taste here where one either feels delight at the clever twist, or the total opposite, rarely anything in between. I happen to dislike these kinds of things (and particularly loathe code ligatures) but it is often hard to justify exactly why beyond taste.
Code ligature thing has something to do with just seeing the characters that are actually there rather than a smokescreen, which IMO impedes editability because I can't place the cursor half-way through a ligature and so on. But it's more than that -- you could fix those functional issues and I'll still dislike them.
> I can't place the cursor half-way through a ligature and so on.
That sounds like a bug in the editor. Ligatures are incredibly common font features even outside of programming, even sequences like fi are often ligatures.
How could this possibly be done for ligatures which don't maintain their horizontal position though? `!=` will usually be shown as an equals sign with a line through it right down the middle.
Adding something to the end is the most common thing to do.
And changing the start is extremely rare - it's anyway special because you usually put it in the line with the SELECT.
No, you usually don't. That would "bury" the first field so you don't immediately see it if you quickly glance at the code. I'll admit I was a bit surprised when I saw a fully formatted SQL query but it does look much better:
SELECT
a,
b,
c,
d
FROM
Customers
ORDER BY
b,
c DESC
Edit: I've just seen other comments here suggesting you return an extra "pad" value at the start so you can use leading commas without "losing" the first value visually. I hardly know where to start with that. It transmits more data on the wire and, to my eyes, looks horrific. That level of hackery is proof, as if it were needed, of how badly needed trailing commas are.
> Any new style will look bad, simply because it is new to us.
I agree that new styles and syntaxes can take some getting used to. When I went from Pascal to C, braces seemed awful but I now think punctuation is much clearer than words for delimiting blocks.
But the discussion here is about whether to introduce a new clearer style. Taken on this context, your comment amounts to defending any existing syntax, no matter how horrific, because you'll get used to it eventually.
> But the discussion here is about whether to introduce a new clearer style. Taken on this context, your comment amounts to defending any existing syntax, no matter how horrific, because you'll get used to it eventually.
No, I'm not defending any existing syntax.
As I said, it is about minimizing errors. You can get used to anything. But some styles and syntaxes are more error-prone than others. Leading commas in SQL is less error-prone, and therefore is preferred. No matter what your initial aesthetic impression. Allowing extra trailing commas is not portable, and therefore will increase errors if you come to rely on it then move between databases. So if the feature is provided, I will still be slow to adopt it into my style.
I always do this. There's usually one field that you can put at the start that never changes. But the field at the end will keep changing as you add more fields to the SELECT list.
SELECT
a
,b
,c
,d
FROM
Customers
ORDER BY
b
,c DESC
reordering, insertions and deletions much easier within the IDE as you’re manipulating lines as a whole. focus maintained while you are in the zone or tired is the biggest gain
at the cost of slightly uglier code and a miniscule… truly miniscule wire overhead.
other decisions will have much larger wire impact, say choosing a column wider than necessary
I'm curious why you think so? I agree totally with the parent comment; when I iterate on a SQL query the most common place to make changes is near the end of the SELECT block, adding and removing and refining column expressions. I do the exact same "comma first" trick to make my life easier.
I only write SQL for complex grouping operations, otherwise the Django ORM is superior. And in those situations, the ordering is really not very relevant, and thus changes can occur anywhere.
> Code ligature thing has something to do with just seeing the characters that are actually there rather than a smokescreen, which IMO impedes editability because I can't place the cursor half-way through a ligature and so on
Why wouldn't that be possible? (The cursor thing)
It's still two characters as far as your editor is concerned.
I didn't say it's not possible, but certainly when I've tried ligatures in the past my editor treated it like a single character until I pressed backspace after the character (or delete before) or whatever. Anyhow there's all sorts of weird functional artefacts that just feel dodgy to me and they basically all arise from this world where multiple runes are being treated as a single one. Here are two more examples:
1. If I `/=` in vim (find equals signs), should the "!=" ligature be highlighted? If it is, then it is misrepresenting the state: if I then press delete, the highlighted ligature won't actually be removed, only part of it will be.
2. In javascript the `===` operator is less visually distinct from `==` since if there are no comparisons nearby I have to judge from the length somehow and it takes longer, adding some additional comprehension fatigue.
Anyway like I said, you can probably try to fix all of these with weird special case handling but it's just fighting the underlying assumption my editor makes (and my brain has learned to understand): a source file is a list of runes. That's how I like to think about it.
Anyone is free to think otherwise. They're just in that other camp and that's OK. But I don't like them personally.
Among the editors which handle well ligatures is Geany.
The cursor moves always over a character, regardless whether it is part of a ligature or not. You can select and delete or replace only a part of a ligature, exactly in the same way as when using a font without ligatures.
The only thing that ligatures change is the visual appearance of the text, which is in my opinion an extremely useful workaround for the inertia of the legacy programming languages, which continue to use the restricted ASCII character set, which has never included all the characters that would have been needed in a programming language.
Now with ligatures, we are finally able to write an ALGOL 60 program that looks like it was intended to look, 65 years ago, instead of being forced to use awkward combinations of ASCII characters, like later programmers and designers of programming languages have resigned themselves to do, because of the character set limitations that the American manufacturers of computing equipment have been unwilling to remove (causing problems not only to programmers, but also to the users of non-English languages).
ASCII has never been intended to include the characters required for writing mathematical expressions. ASCII has been intended only to include the set of characters that were in use in the commercial correspondence written in English, which had been previously available in the better typewriting machines. Because of this, ASCII has always been bad as a character set used for a programming language.
I'm not sure if this is an example of code ligatures, but I used to work with a guy who had configured his editor so that "=>" was replaced with some kind of special arrow character, and it used to drive me nuts. When I read code, I want to know what's actually there, and not have to ask "what does that arrow actually mean?"
But you have demonstrated that you know what the arrow means. Do you have your editor configured to display special symbols for all whitespace characters? Including newlines? Are you sure that you aren't just annoyed by looking at stuff you're not used to?
when chrome started hiding the https prefix from urls it still showed the same information as https was the only hidden prefix, yet a lot of people were similarly upset.
Code ligatures make text harder to read because they are not text, expecially when many of those ligatures are identical to actually existing unicode characters making the gliph more ambiguous than they laready were.
IMHO symbol should reflex their use: the dozens of different arrows used in math are meant to be handwritten or at least to be seen as a complex gliph.
=> and -> in almost every programming language is a = or a - followed by a >. We could very easily make a language where ⇒ is an operator (https://isabelle.in.tum.de/ does for example IIRC) but most languages use simple ascii characters for grammar for good reasons.
IMHO code ligatures are worse than a cursive coding font.
> Do you have your editor configured to display special symbols for all whitespace characters? Including newlines?
I actually have my editor configured to display special symbols for all control characters except U+000A NEW LINE (that includes U+0009 HORIZONTAL TABULATION as well, this is actually a control character, not a whitespace) and all whitespace characters except U+0020 SPACE.
You have simply moved the "special" entry to the beginning rather than the end.
Side remark: I've noticed that when it comes to code formatting and grammar it's almost like there are broadly two camps. There are some instances of code formatting that involve something "clever". Your example of leading commas above for example. Another example is code ligatures. It's as if there's a dividing line of taste here where one either feels delight at the clever twist, or the total opposite, rarely anything in between. I happen to dislike these kinds of things (and particularly loathe code ligatures) but it is often hard to justify exactly why beyond taste.
Code ligature thing has something to do with just seeing the characters that are actually there rather than a smokescreen, which IMO impedes editability because I can't place the cursor half-way through a ligature and so on. But it's more than that -- you could fix those functional issues and I'll still dislike them.