4 ms·

I liked this comment: ``Good programmers already pad looser operators more often than tighter operators.''. I liked it because I have never done this, and don't

by to3m 11y ago

I liked this comment: ``Good programmers already pad looser operators more often than tighter operators.''. I liked it because I have never done this, and don't recall working with any code that does. Most I've seen is unary operators having no space, e.g., x + y * -z. (Though it's always possible I'm misremembering, of course. Naturally, good programmers know to just ignore the spaces, in case they're misleading.) As time goes on, I imagine more and more text editors will format your code in a fixed way, making this sort of thing impractical anyway. Not just automatic indentation, I mean, but adding spaces in around operators and ensuring brackets are in the desired place and removing blank lines and so on. GFA BASIC did this sort of thing on the Atari ST in the early 1990s, as did Visual BASIC, I think, in a few years later. Visual Studio has done this for C# since VS2008, more recent versions of Visual Studio will do this for C/C++ too, and there's a long tradition of command line-driven formatters for C-like languages that you could also use. Go's large - but not comprehensive - collection of features beginning with `g' includes gofmt, and I've no doubt Java IDEs will do this sort of thing for you too. And this autoformatting trend is bound to continue, because... well, why wouldn't it? But it does mean - if it's to be done properly, and in some way that won't mean you have to reach for regular expressions to search for even the simplest snippet - that you can't leave spacing decisions up to the programmer.

vidarh 11y ago
The only way you'll get enforced formatting to work across the board, is if the editor can safely roundtrip between the "official" format and the developers preferred format.
- to3m 11y ago
  There's no round trip in the editors I've used. You have the standard formatting, and that's it. What you type in will get rearranged in situ so it's in the right format. If you prefer something else - well, good luck with that, because you can type it in, and it will compile, but you run the risk of somebody doing something that will cause the file to be reformatted and you'll end up with the standard layout anyway. Best get used to it now. (As I understand it, gofmt is very similar.) This functionality is actually a benefit, because you can type in something like this: public Fred(int[]x):base(x){ UpdateStuff();} and the editor sorts it out, something like this: public Fred(int[] x) :base(x) { UpdateStuff(); } No need to wear out your space bar and/or Return key putting the formatting in. Visual Studio has got a fair idea of what sort of stuff might have been formatted thet way deliberately, too, so single-statement controlled statements won't get their own line by default, and when opening and closing braces are on the same line the code is left that way. It pretty much always just works. (C/C++ isn't quite as good - maybe 85% of the way there.) I don't really have a problem with automatically making everybody's code look pretty much the same.
  - vidarh 11y ago
    > There's no round trip in the editors I've used. My point exactly. It's an incredibly hard problem. > You have the standard formatting, and that's it. Which is why I don't use any of those editors, and won't ever do so. > This functionality is actually a benefit, because you can type in something like this: Every editor I've used in the last 20-30 years or so has been able to do that, but none of them have forced me into a specific formatting that I can't override. That's the difference. > I don't really have a problem with automatically making everybody's code look pretty much the same. Well, I do, and enough people I've worked with do (EDIT: The issue is not making everybody's code the same; the issue is that I'm not willing to have a specific format dictated to me and so unless everyone will format their code like me I won't use tools that attempt to force a single style), and so any attempt to standardise tooling like that just ensures that environment/language has one more barrier against adoption. There's plenty of people like me that avoid Python "just" over significant indenting for example.
    - to3m 11y ago
      Well I did say that I expect fixed formatting will become more common over time. Having to press the space bar less is one reason. Discussions such as this one are another ;)

by to3m 11y ago

vidarh 11y ago

The only way you'll get enforced formatting to work across the board, is if the editor can safely roundtrip between the "official" format and the developers preferred format.

to3m 11y ago
There's no round trip in the editors I've used. You have the standard formatting, and that's it. What you type in will get rearranged in situ so it's in the right format. If you prefer something else - well, good luck with that, because you can type it in, and it will compile, but you run the risk of somebody doing something that will cause the file to be reformatted and you'll end up with the standard layout anyway. Best get used to it now. (As I understand it, gofmt is very similar.) This functionality is actually a benefit, because you can type in something like this: public Fred(int[]x):base(x){ UpdateStuff();} and the editor sorts it out, something like this: public Fred(int[] x) :base(x) { UpdateStuff(); } No need to wear out your space bar and/or Return key putting the formatting in. Visual Studio has got a fair idea of what sort of stuff might have been formatted thet way deliberately, too, so single-statement controlled statements won't get their own line by default, and when opening and closing braces are on the same line the code is left that way. It pretty much always just works. (C/C++ isn't quite as good - maybe 85% of the way there.) I don't really have a problem with automatically making everybody's code look pretty much the same.
- vidarh 11y ago
  > There's no round trip in the editors I've used. My point exactly. It's an incredibly hard problem. > You have the standard formatting, and that's it. Which is why I don't use any of those editors, and won't ever do so. > This functionality is actually a benefit, because you can type in something like this: Every editor I've used in the last 20-30 years or so has been able to do that, but none of them have forced me into a specific formatting that I can't override. That's the difference. > I don't really have a problem with automatically making everybody's code look pretty much the same. Well, I do, and enough people I've worked with do (EDIT: The issue is not making everybody's code the same; the issue is that I'm not willing to have a specific format dictated to me and so unless everyone will format their code like me I won't use tools that attempt to force a single style), and so any attempt to standardise tooling like that just ensures that environment/language has one more barrier against adoption. There's plenty of people like me that avoid Python "just" over significant indenting for example.
  - to3m 11y ago
    Well I did say that I expect fixed formatting will become more common over time. Having to press the space bar less is one reason. Discussions such as this one are another ;)