4 ms·
We really should stop formatting the actual code to make it 'readable'. The editor or IDE should take care of formatting the displayed code to our preferences w
by siempreme 7y ago
We really should stop formatting the actual code to make it 'readable'. The editor or IDE should take care of formatting the displayed code to our preferences with a built in linter/prettier. That should end the pointless and annoying discussion.
- bartwe 7y agoYeah following simple formatting rules is a job we can (and should) give to the computer.
- wruza 7y agoProblems arise when you refer to lines/columns which are different from what you see by preference. I believe there will be much more friction in line-based tools than in people who do not like a particular style.
- badsectoracula 7y agoQBASIC got that right decades ago :-P
- lonelappde 7y agoBASIC. QBASIC mostly removed line numbers.
- badsectoracula 7y agoI was referring to the automatic formatting that QBASIC did.
- slx26 7y agoI read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are saying is much more interesting, as we are all allowed to keep our preferences. Is there any major editor/IDE working on this? You are making me miserable, now that I read this I can't live with just formatters anymore :D
- lonelappde 7y agoEvery editor can do this. Apply your formatter when you load a file, and apply the standard formatter whenever you submit a file to another machine.
- davnicwil 7y agoSo, this is indeed a very cool idea, the fundamental issue you'd have though is that you can't abstract away from the 'ground truth' formatting at the source control level. You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth formatting. That's not even to mention doing stuff like PR reviews in online tools, not in your local editor/IDE. Going back and forth between the two like this would probably just be counter productive, you're better off just thinking in terms of the ground truth formatting from the start, I'd say. I think while it might be possible under a very narrow set of limitations and usecases, it's probably just a very leaky abstraction to try to 'hide' the actual formatting of code in a text file.
- slx26 7y agoI can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online. I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hiding" the formatting. In my view, it's more like opening a web page with one browser or another, or with one device or another. It always looks a bit different. Or maybe I have a theme configured on my main browser or whatever. I like to have my preferences, but if I have to look at the page from another browser, it's not a big deal either. The extra configuration might not be worth it or slightly inconvenient in some cases, but I doubt it's counter productive. The same way as I might prefer to read/write with a certain font or use this or that color palette. Maybe the takeaway is that code is more personal for some people than we like to generally admit. You are talking in a language and you want to be able to express yourself as comfortably as possible. I mean, we have had turing-complete and even "productive/decently ergonomic" languages for a while, and yet a lot of people keeps coming up with new languages, because they are much more than just a tool to get things working. We want to express ourselves as we "think", and formatting may be a small part of that, but it's still a part of it. [0] https://github.com/forest-lang/forest-compiler https://github.com/forest-lang/forest-compiler