17 ms·

The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. It's 2013. Let's fix the tools. You

• alexchamberlain 13y ago
  I'm sorry, but I disagree. As it stands, it is currently more important to display code as it appears in the file. One day, everyone may have their style for all languages and every tool supports it etc. That's not today.
  • jowiar 13y ago
    I agree. I'm saying this is a bug. The fact that we need to care about this is a bug. If I'm working with code on my phone, I'm going to have different preferences than on my tablet, or my laptop, or doing side-by-side comparisons, or my 30" display, or a projector. Probably the best current examples of what can be done with this are docco and it's friends. iPython notebook is another example of what we can do when we decide that hardware improvements in the past couple decades may be taken advantage of to improve production and consumption of code, rather than declaring that no progress shall be made after 1976.
    • marssaxman 13y ago
      The hardware may have improved, but the meatware has not. We don't use narrow, fixed-width columns because of technical limitations, but because they are easier for human beings to read.
• frou_dh 13y ago
  Alrighty. Where will you be implementing it first?
  • NegativeK 13y ago
    And how will you get every editor available on board?
    • jowiar 13y ago
      Does it matter? Progress sometimes requiring taking a couple steps backward if we've reached a local maximum. An unwillingness to compromise backward compatibility - a perennial commitment towards designing for the lowest common denominator - limits the progress that can be made.
      • burntsushi 13y ago
        > An unwillingness to compromise backward compatibility Are you referring to the unwillingness to bump up the maximum line length? I don't think it's because of backward compatibility. I limit just about every line of code I write in any language to 80 columns, and my horizontal screen real estate is 5760 pixels.
• _ZeD_ 13y ago
  Code is meant to be consumed by machines I hope you're joking...
  • jowiar 13y ago
    Poor word choice on my part. The intention was that machines don't need to jump through any hoops to be able to figure out what code means - it's a language designed such that it can be parsed mechanically without ambiguity. Compare this to a machine interpreting English. I was not intending to downplay the significance of code being intended for human consumption.
    • zeckalpha 13y ago
      But how many characters are in a typical line of English?
      • numbsafari 13y ago
        It depends on your typography.
      • baddox 13y ago
        More than 80.
        • deleted 13y ago
          [deleted]
      • kps 13y ago
        Traditionally, Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. — Robert Bringhurst, The Elements of Typographic Style, 3rd Edition, §2.1.2
• rlpb 13y ago
  Find me an alternative to side-by-side diff tools (such as meld) that work poorer with longer lines, and then we can talk. Code is simply easier to read by humans when it isn't stretched out obtusely in one direction. We should be making code easier to be read by humans. Machines don't matter.
  • deleted 13y ago
    [deleted]
• dilap 13y ago
  Completely agreed. Newer versions of emacs do nice code wrapping (dynamically, to the width of the buffer, without modifying the buffer text). Xcode does nice code wrapping. I've stopped manually wrapping my code, and it's great.
  • rlpb 13y ago
    What do you do when you view a diff, and what you see there doesn't match your editor? Edit: I know emacs can probably view diffs. That's not the point, unless you expect every window to be the same width, and every tool to wrap everything exactly the same.
    • coldtea 13y ago
      >What do you do when you view a diff, and what you see there doesn't match your editor? Mentally account for one more line or two?
    • dalore 13y ago
      We should fix the diff tools too while we are at it. Why are we diffing by lines and not doing a semantic diff of the code? If the compiler doesn't care about it, why should the diff?
      • spenczar5 13y ago
        Not all languages are compiled - sometimes line breaks are meaningful, and it would be good if diff tools work across all languages.
      • RogerL 13y ago
        Scaling. The same diff tool works for text files, latex and other markup files, for any computer language, and so on. I can write downstream tools that take the output of the diff and do further processing, without worrying about what the output might look like for brainfuck. And how long would we have to wait for Torvalds to add a C++ or Java extension to git? :)
      • rlpb 13y ago
• memset 13y ago
  I upvoted you for this - I think it's a really interesting idea. Why can't my editor tokenize my code and then show it in the format I want? Why do I, as the programmer, have to worry about whether one whitespace convention works for you versus me, when you could just come up with whatever scheme you like and view code that way?
  • coldtea 13y ago
    >Why can't my editor tokenize my code and then show it in the format I want? Because editors are written by humans. And as of now, we haven't sold a whole lot of problems with their use. For example, you get an IDE with lots of features, but a subpar editor, crammy UI and GC pauses (3 of the five most popular are written in Java). Or you get something like VIM, with a great editor, but subpar compatibility with the rest of your system, not very good understanding of the code (refactoring, tokenizing etc). '80s GUI capabilities etc, ad-hoc collection of plugins to fix basic pain points (like file navigation). Or you get Emacs, with millions of configurable options, a subpar extension language, script in various stages of great and rot, '80s GUI capabilities, etc. In general, we lack tools that run the whole gamut: great editor, fluent shortcuts (either Emacs or Vim style), 2013 GUI capabilities, refactoring and intimate knowledge of program syntax (to the level of understanding the AST, no BS regex used for syntax highlighting), embedded REPLs and terminals, etc. Something like a Lisp Machine + Smalltalk UI + Light Table + Visual Studio + Vim/Emacs combo.
    • ardacinar 13y ago
      "something like VIM, with a great editor, but subpar compatibility with the rest of your system" Excuse me, but vim has much better compatibility/interoperability with the rest of my system than all the IDEs written in Java.
    • blt 13y ago
      Visual Studio with a VIM emulator plugin is pretty nice...
    • qu4z-2 13y ago
      Between ^Z, :<range>!, :grep, make, and other tools, vim has great compatibility with my system, thanks :)
• jayferd 13y ago
  "Code is meant to be consumed by machines" Well, partly. Code is actually a piece of writing intended for two very different audiences - one human, one machine. The machine doesn't actually care how long your lines are - this is an optimization for humans. And I hear you about fixing the tools. Wouldn't it be easy if everyone used the same editor. But alas, this isn't a problem with the tools. It's an inherent limitation of text. That "figuring out visual structure" bit only works if your editor deeply understands your language. And different editors understand languages to different degrees and in different ways. They say parsing is a solved problem, but I dare you to parse Ruby or Python correctly.
  • chrismorgan 13y ago
    While Ruby and Perl cannot be parsed, Python can be parsed correctly.
    • elnate 13y ago
      I don't understand what you mean by parsing if not what the interpreter does. Can you give an example?
      • SoftwareMaven 13y ago
        Perl (and I assume Ruby from the comment) requires the running context of the interpreter to make decisions about how to interpret some code constructs. Because you need the running state, it is not parseable.
      • lmm 13y ago
        Parsing as in determining what constructs different lines represent, without running them. Imagine e.g. a documentation generator that needs to figure out what all your methods and parameters are, but not actually execute them (obviously there are many other use cases). A friend at an old job had a piece of perl code where one of the lines would be a comment or not when you ran it, depending on user input. He would bring it out whenever someone suggested writing something in perl.
    • 13y ago
• eevee 13y ago
  No, thanks. Reasonably short lines means I can get a good idea of what's going on by skimming in one direction: downwards. If there are lines that run off towards the eastern horizon, even if they fit on my screen, I still have to follow along them to make sure nothing of interest is being hidden. Plus, just getting the code to do the thing I want is enough work; let's not also start worrying about how to write code in such a way that most tools will understand how to wrap it. That sounds like bringing all the joys of CSS to my plain text. Because the tools are _not_ going to be perfect. Have you ever seen Perl code with punctuation in a comment at the end of a line, because some idiot syntax highlighter got confused about where a regex ended?
• d23 13y ago
  I'm disappointed to see this is still the top comment, for a few reasons. 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. 2) You should be taking the time to figure out how to maximize readability of your code. And breaking the lines is damn near instantaneous when compared to the time taken to pick a good variable name or decide on overall design structure. 3) Not everyone will have the same editor. Your code should stand on its own and be readable in its own right.
  • baddox 13y ago
    > 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8: def __init__(self, width, height, color='black', emphasis=None, highlight=0): What about that code is "too verbose"? It's an extremely simple constructor with 6 arguments (5 explicit). I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.
    • stormbrew 13y ago
      Exactly. 80 columns with python is incredibly frustrating to hold to. Python is a verbose language at the best of times, when you add in 4 or even 8 column indent it's just silly. 20% of your line is probably taken up by leading spaces or one or more 'self.'s. The introduction of keyword args only compounded the issue.
    • acjohnson55 13y ago
      I think it's worth the time to spend a little while with an IDE that PEP-8 checks your code in real-time. It really forces you to think about better formatting and breaking up complex statements. In your example, if my declaration is running that long, I put the first line break after the open-parenthesis. Then all parameters end up in a nice block, and I've found that to be very easy on the eyes when going back to look at forgotten code. Generally speaking, I've found that adhering to the 80-char limit has greatly improved my code formatting and readability. 100 is okay with me too, though.
• crististm 13y ago
  That is in stark contrast to SICP: "programs must be written for people to read, and only incidentally for machines to execute" Whom should I listen to... Hmmm, tough choice... I mean, I've just seen Gerry Sussman in a recent video saying he doesn't know how to compute, so you must be a winner.