Please don't feed this troll. On Mon, Apr 24, 2017 at 10:42 AM, <john.deig...@gmail.com> wrote:
> 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. > -- 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.
