7 ms·
I think this is a subject most editors fail to address. A single line of code should be written to file as a single line - no matter how long. However, the edi
by DoubleGlazing 6y ago
I think this is a subject most editors fail to address.
A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings.
Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator or a dot in a function chain. Wrapped lines could be tabbed or visually flagged to let you know.
In other words there should not be am ideal line length for code, but instead editors should be able to adapt to make life easier for developers.
Look at word processor documents, imagine how much of a nightmare it would be if such documents had a hard limit of characters per line.
- EsotericAlgo 6y agoIs it an issue of editors or of language? The amount of errors that incorrect whitespace characters cause in whitespace sensitive languages could attributed to editors obfuscating what's written to file. I think the pragmatic solution is an opinionated linter that can be broken.
- falcolas 6y agoEven vim handles word wrapping well. A text editor which can't... well, it's a pretty poor text editor then, isn't it? That said, I don't know of many text editors (outside of notepad, and even that's gotten better lately) which don't offer options about how to (or not to) wrap text.
- smabie 6y agoNo text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.
- bryanrasmussen 6y agoWhen I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet. So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.
- fiddlerwoaroof 6y agoIf you modify breakat and a couple other options (foldindent, to make the autowrapped lines stand out from the others), you can make vim’s autowrapping a lot nicer for word-wrapping code.
- deleted 6y ago[deleted]
- Terretta 6y ago> wrap gracefully at logical point in the code This is so clearly right, how can it not yet exist? ‘Just’ dynamic virtual pretty print per personal lang style prefs.
- jsolson 6y agoXcode on OS X has been doing this for at least one decade.
- travisjungroth 6y agoOne thing that's a little tricky is once you do that, the real code doesn't match what's on the screen. Not so bad if it's just whitespace, a little worse if you have to add characters to allow the line breaks. Still, I'd like it and would probably use it. I'm sort of a sadist in that I like 120 width, even though I can't quite go 2 windows wide on my laptop. I just side scroll like a peasant.
- grok22 6y agohttp://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/ http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro... might explain why 'just' doing the pretty print on the fly might not be a easy thing (even if the problem here is limited to a single line of code and something based on line length).
- zeroimpl 6y agoThis would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets. That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.
- Semaphor 6y agoNot always. I can set the breakpoint in jetbrains rider to a function in a multi function line. And Java stacktraces certainly contain character offsets.
- zeroimpl 6y agoI’ve seen character offsets for JavaScript (which requires it due to minimization), but never Java. I’m pretty sure that data is not available in Java bytecode, nor most compiled languages.
- yellowapple 6y agoThe editor could show both the final line number and "sub-line-numbers" after a decimal point or something. E.g.: 1 /* A function that does something */ 2.1 int do_something(int foo, 2.2 int bar, 2.3 int baz) 2.4 { 2.5 return foo + bar + bam; 2.6 } Which would condense to: 1 /* A function that does something */ 2 int do_something(int foo, int bar, int baz) { return foo + bar + bam; } When you try to compile this, the compiler will complain about line 2, which you know from your editor's line numbering encompasses lines 2.1 through 2.6. As an alternate strategy, you could use column numbers instead of sequential sub-lines, like so: 1 /* A function that does something */ 2.0 int do_something(int foo, 2.26 int bar, 2.35 int baz) 2.44 { 2.46 return foo + bar + bam; 2.70 } And then, if the compiler reports a column number or offset into the line, you'll immediately know "well the compiler's complaining about line 2 column 65, which is between 2.46 and 2.70... golly gee willikers, I fat-fingered the third addend in the return statement!". You could get even more abstract than this, with "line numbers" instead being local to a given scope, and the compiler reporting erroneous line numbers relative to said scope. If the compiler tells you that the syntax error is in the first (in this case also last) statement in the function do_something, then it should be apparent where to look.
- sesuximo 6y agoNow that you’ve said it you have to make it happen!