One of the things that I learned early in life is to recognize B.S. when I see it. My B.S. flag went up first when I read where someone claimed that "artifacts" are bad and detract from the readability of code. A compact and well-defined artifact, like the semicolon, makes code *more* readable because the programmer's intent is crystal clear, whereas removing them leaves one guessing exactly where a line ends. The rules are considerably more complex - not to mention vary across languages, than the simple "it ends at the semicolon" rule.
Now I read that the programmer's preference is irrelevant (I hope that we can agree that the programming community consists of individual programmers!). Well, that flag just shot up again. There's no reason that an individual's preference can't be respected when he's editing code, even if way that the code is stored on disk is the same. That's why I exclusively use TAB characters for indentation - some people prefer to see 2 spaces per level of structure, I prefer 3 spaces and someone at my company prefers 8. We get to see what we prefer without requiring any changes to the code itself. So, here's my current thinking about long lines/continuation lines, take it for what it's worth. There should be no such thing in a language. A long line should just be a long line, without limit, in the source file. After all, it's not the compiler that wants to split long lines so that they are more readable - it's the programmer when using a text editor or code viewer. Think how much simpler a compiler would be if it could just assume that a simple (i.e. non-compound) statement always exists on a single line! It's the editor that should display a single simple statement on multiple lines on the screen. In fact, the editor could provide visual cues that a single statement is being displayed on multiple lines on the screen, such as a light gray background color, underlining, box around it, whatever. The point is that the individual programmer's personal preference would be used without affecting the saved format of the code. For that to work well, the editor would probably have to understand the syntax of a statement so that the line splitting will result in something that the programmer finds readable. I don't know if a current editor that can do that. But line splitting is something that the compiler should *not* have to deal with. After all, it's the programmer using an editor that cares about making long lines readable, not the compiler. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
