I won't. I'm done with this thread. On Mon, Apr 24, 2017 at 10:52 AM David Peacock <david.j.peac...@gmail.com> wrote:
> 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.
