1. 3
  1.  

  2. 5

    instead of an option “only check *.go files” why not just have a files filter option and allow it to check any filtered list of files?

    1. 3

      The only check go files is a shortcut, basically for $ find . -name *.go | lll --files. I want to add the linter to gometalinter https://github.com/alecthomas/gometalinter/pull/93 and it seemed nice to have a shortcut for go files. But the filter functionality is possible with the --files flag. Perhaps I should add a filter flag too though. Another flag that is “go specific” (not really since vendor is a commonly used name) is the --vendor flag, which is just a shortcut too.

    2. 3

      It would be very nice if this was just a feature of gofmt, and appropriately formatted lines that were too long.

      1. 4

        I would be rather displeased with that, artificial line length limits I think tend to create very ugly code. We don’t deal with punchcards or fixed width terminals – if you have to crank it up to 91 chars for a clean line, go for it, be wild and crazy! Editors can wrap if need be. There are lots of things I like gofmt taking care of but line length and function order I am happy it doesn’t touch.

        1. 3

          I used to think this way about line lengths – that 80-char line limits were just an unnecessary remnant from a bygone era – but I learned that they have an important modern use. Sticking to 80-char lines and adjusting your font size means you can stack three columns of code neatly on a 24" widescreen monitor (more with a 30").

          1. 4

            How is 80 any better than 120, or 92? Depending on resolution, font and monitor size – some combination will fit in 3 columns or 5 columns… on your screen, on some other 4K monitor, a different magic combination will exist. It is an arbitrary quark of history that could easily have ended up being some other number. .

            1. 2

              80 isn’t better than the others, it’s just that enforcing some kind of line limit can be better than not. It just so happens that the project I work on has standardized on 80, so I referenced it in my comment.

              1. 2

                it’s just that enforcing some kind of line limit can be better than not.

                Yep, and that is a fine perspective. I happen to believe the opposite. I believe this is a decision best left to humans. I don’t think much should be left to humans format / layout wise, but line length and function order are two of the big ones. I think humans are fairly good at understanding a sane line length, and understanding when breaking a line will add or detract from the readability of the code at hand.

              2. 2

                80 also fits two columns on my laptop with a readable font size. Short columns are also easier to read than long ones.

                1. 1

                  I think there’s some value to familiarity and consistency, but of course, there are several different norms in different communities. Probably nobody prefers 40-char code or 400-char code, but in between…

                  Unix people seem to mostly consider the classic standard of 80 chars to be optimal, although my read is that the 80-char consensus is weakening even in Unixland. In the IDE world, something like 120 characters is often considered the modern standard, and 80 is seen as annoyingly skinny. You can see those differences in various tools' and editors' defaults: refactoring/reflowing in emacs defaults to 70 chars, vim to 80, and JetBrains ReSharper to 120.

                  1. 3

                    But, it all is sort of based on historical quarks… 72 was the how wide Manning could publish. 80 was the width of a punch card, 132 was high res VT100 and Fortran / Dot Matrix Printers… 78 was email if I remember correctly… 79 was leaving the extra space for a scroll bar… again, there were a LOT of “standards”… which all do fall in your 40 to 400 rule for sure.

                    EDIT: I didn’t even realize 120 was becoming the new 80 in IDEs, but a little digging seems to confirm a lot of the big beefy IDEs do lean that way. I obviously don’t spend too much time outside of Vim.

                2. 2

                  I think in general limiting lines to something reasonable (I like 80 because it’s just narrow enough to fit three columns side-by-side on a 1080p monitor at a readable font size) is good, but setting hard limits almost always causes more trouble than it’s worth. I’m not figuring out where to break that line that overflowed by a semicolon and has no obvious internal splits, and I think long explanatory comments are better wrapped by the editor than by hand (if for no other reason than so the linebreaks don’t get screwed up every time someone edits them).

                  If you’re regularly ending up with very long lines, the code you’re writing is probably either bad or highly non-idiomatic anyway. I’m fine with bucking language idiom if you know what you’re doing, but come up with a suitable indentation scheme while doing so.

                  1. 1

                    It can also mean, that instead of 3-4 functions that fit in one column of your editor, you can now only see 2 of those functions, so a column limit does not necessarily increase the amount of code you can put onto one screen. A reoccuring pattern I see is that people who worry a lot about column limits use IDEs with Project Trees and Class hierarchy panes. No wonder are they worried about horizontal screen space.

                  2. 2

                    I don’t know whether gofmt should wrap lines or not. I’m fine with it how it is. With that said…

                    Editors can wrap if need be.

                    No. Non-breaking line wrapping is grotesque and very difficult for me to read.

                    We don’t deal with punchcards or fixed width terminals

                    This straw man needs to die. Just because we don’t have punchcards or “fixed width terminals” doesn’t mean there aren’t good use cases for keeping code to a column limit. For example, given an N column limit and sufficient screen real estate, it might be possible to have multiple code windows side-by-side on a single monitor and be able to read the code without the editor having to do ugly automatic line wrapping.

                    1. 2

                      No. Non-breaking line wrapping is grotesque and very difficult for me to read.

                      How is that any more valid than my personal preference of being fine with wrapping and hating unnecessary arbitrarily forced breaks based on historical norms? Yeah, well, that’s just, like, your opinion, man.

                      This straw man needs to die. Just because we don’t have punchcards or “fixed width terminals” doesn’t mean there aren’t good use cases for keeping code to a column limit. For example, given an N column limit and sufficient screen real estate…

                      N can only be set for an individual developers setup, it is useless generally. There is some GREAT number for your setup – maybe it is 72, splits perfectly into 3 lovely columns. Maybe that is AWFUL on my setup. Rather than trying to endlessly debated screen layouts vs. line length which is the definition of arbitrary, write the code in a way that is reasonable and clean and don’t worry about line length, worry about readability. You can’t possibly know all the configurations your code will be viewed in.

                      1. 1

                        How is that any more valid than my personal preference of being fine with wrapping and hating unnecessary arbitrarily forced breaks based on historical norms? Yeah, well, that’s just, like, your opinion, man.

                        This is a new one. I’ve never heard of anyone saying that code with a column limit is hard to read. I guess I can imagine some interesting cases, but if they’re rare, then either (1) refactor or (2) break the column limit.

                        N can only be set for an individual developers setup, it is useless generally. There is some GREAT number for your setup – maybe it is 72, splits perfectly into 3 lovely columns. Maybe that is AWFUL on my setup. Rather than trying to endlessly debated screen layouts vs. line length which is the definition of arbitrary, write the code in a way that is reasonable and clean.

                        This is unnecessarily reductive. Conventions have value all on their own, regardless of their origin. There are a few values of N that have widespread adoption.

                        1. 2

                          This is a new one. I’ve never heard of anyone saying that code with a column limit is hard to read.

                          Almost all the complaints about line limits are about code readability and arbitrary breaks making code ugly and harder to read – I haven’t really even seen another argument against line limits, as the computer doesn’t care, it is purely code aesthetics.

                          I guess I can imagine some interesting cases, but if they’re rare, then either (1) refactor or (2) break the column limit.

                          This doesn’t really make sense in the context of Go. The context of Go and gofmt is automated consistent formatting, it is most often entirely automated either in editor, or on commit to version control, that makes option (2) challenging, needing special syntax or exceptions. As for option (1) – refactoring code due to an arbitrary line limit rather than any actual need seems counterproductive.

                          This is unnecessarily reductive. Conventions have value all on their own, regardless of their origin. There are a few values of N that have widespread adoption.

                          The “common” Ns I have run up against are 72 (Manning Publishings limit), of course, the “classics” of 80 (java) or 79 (python) or 100 (android) or 132 (Fortran, VT100 high res, dot-matrix printers)… that is a fairly big spread of “classic N” for my taste.

                          1. 1

                            Almost all the complaints about line limits are about code readability and arbitrary breaks making code ugly and harder to read – I haven’t really even seen another argument against line limits, as the computer doesn’t care, it is purely code aesthetics.

                            I know. I’m saying I’ve never heard anyone say column limits make code harder to read.

                            Certainly, I can imagine that certain programming languages might suggest using longer limits…

                            This doesn’t really make sense in the context of Go.

                            I note that I already said this:

                            I don’t know whether gofmt should wrap lines or not. I’m fine with it how it is.

                            .

                            As for option (1) – refactoring code due to an arbitrary line limit rather than any actual need seems counterproductive.

                            Seems like a pretty good heuristic to me. And a column limit isn’t arbitrary. The actual limit chosen may have weird origins, but the choice to have a column limit needn’t be arbitrary.

                            The “common” Ns I have run up against are 72 (Manning Publishings limit), of course, the “classics” of 80 (java) or 79 (python) or 100 (android) or 132 (Fortran, VT100 high res, dot-matrix printers)… that is a fairly big spread of “classic N” for my taste.

                            So what? Pick one.

                            My point here is that your focus on the origin of these column limits is a red herring. It doesn’t make any sense to dismiss column limits just because some of the limits used in the wild have origins that no longer “make sense.” I’m trying to convey the notion that limits themselves have value with respect to code readability. Just because there isn’t an obviously correct limit doesn’t mean all of them have zero utility.

                            1. 1

                              I’m trying to convey the notion that limits themselves have value with respect to code readability.

                              And I believe that the arbitrary application of line limits is WORSE than allowing a human to make those decisions. We simply disagree, have differing opinions. I believe humans are better at making this specific decision. I also think they are better at organization functions. Which is why I said I would be disappointed if gofmt changed direction and decided to handle either of those things. Luckily, it appears there is no risk of that.

                              1. 1

                                I believe humans are better at making this specific decision.

                                I explicitly said I wasn’t contesting this in my very first comment reply to you so that we could avoid conflating two distinct issues. I even told you that I was fine with how gofmt works now. I was instead taking issue with your weird dismissal based on “punch cards” and “fixed width terminals.”

                                1. 1

                                  My first line was “…artificial line length limits I think tend to create very ugly code.” – that was my primary point, obviously. My secondary point was that all the standards are so insanely arbitrary and pointless based on historical quarks that are meaningless now, and I stand by that. Basically, I feel it is a bad thing to do, and I feel the reason people do it is historical momentum more than reasoned thinking.

                                  1. 1

                                    And people don’t use column limits today because they were once necessary on ancient hardware.

                                    There are lots of people in this thread telling you why they use column limits.

                    2. 1

                      I would expect the line length to be configurable…

                      1. 1

                        Gofmt seems to be about removing configurable options, not adding them: https://github.com/golang/go/issues/7101 (very few currently exist: https://golang.org/cmd/gofmt/)