I'm trying to get a PR I've put up to successfully get thru Travis for Go 1.5: https://travis-ci.org/antonlindstrom/pgstore/jobs/151870208

It appears this package isn't installing properly. I'm not clear whether this is an issue with your package in some way, or the gometalinter package which is installing it. Could you give some direction wrt that please?

Thank you!

The tabwidth argument to lll makes it possible to configure how many characters a tab should be counted as. This is useful for reporting long lines which are indented.

The default value is 1, meaning legacy behavior is kept. By setting the tabwidth, it's easy to get warnings about other tab width settings, such as 4 and 8.

-Fixed a crash (panic) case where the files in arguments do not exist. Instead, a clean error is back-propagated now -Added an exclude optional argument to be able to skip temporary lines (e.g., TODO)

Running this on a piece of code:

$ lll -g -l 100 main_test.go

main_test.go:194: line is 104 characters
main_test.go:211: line is 123 characters
main_test.go:215: line is 149 characters
main_test.go:216: line is 149 characters
main_test.go:217: line is 149 characters
main_test.go:219: line is 117 characters
main_test.go:243: line is 155 characters
main_test.go:256: line is 128 characters

Running the same, but now excluding anything starting with func:

$ lll -e func -g -l 100 main_test.go
main_test.go:210: line is 123 characters
main_test.go:214: line is 149 characters
main_test.go:215: line is 149 characters
main_test.go:216: line is 149 characters
main_test.go:218: line is 117 characters
main_test.go:242: line is 155 characters
main_test.go:255: line is 128 characters

The first report (line 194) is now properly skipped, but all other lines now have an off-by-one issue, where previously line 211 was reported to have 123 characters (which is correct), but now the report says that line is on line 210, which is incorrect.

We have some long imports which exceed our lll length configuration.

We'd like to disable lll from anything inside import ( XYZ ) as there's not really much we can do about these import lengths.

Is there any way this could be added as a configuration?

Thanks!

Hello!

We now have to do this, which is not very beautiful

//nolint:lll
//go:generate mockgen -source=$GOFILE --build_flags=-mod=mod -destination mocks/mocks.go -package eventsubscriptionmocks . IAvailability,IMarketsConfig,ILPClient

I find this annoying, but apparently if you have a really long link, and it's the only thing in the line, it is still being reported. I often put in comments links to other projects as a reference e.g.

// https://github.com/walle/lll/blob/4438bccd245f7e87a5a69023625f01e7035c05c0/utils.go#L15

nolint:lll is also not respected in comments

One of, if not the most popular style guide in the world is the Airbnb JavaScript Style Guide, which represents best-practice across a lot of the JavaScript and TypeScript ecosystem.

In the style guide, it mentions:

6.2 Strings that cause the line to go over 100 characters should not be written across multiple lines using string concatenation.

Why? Broken strings are painful to work with and make code less searchable.

// bad
const errorMessage = 'This is a super long error that was thrown because \
of Batman. When you stop to think about how Batman had anything to do \
with this, you would get nowhere \
fast.';

// bad
const errorMessage = 'This is a super long error that was thrown because ' +
  'of Batman. When you stop to think about how Batman had anything to do ' +
  'with this, you would get nowhere fast.';

// good
const errorMessage = 'This is a super long error that was thrown because of Batman. When you stop to think about how Batman had anything to do with this, you would get nowhere fast.';

This policy seems sensible. With the "bad" code example above, grepping through a project for "thrown because of Batman" would return 0 results.

One other problem with using string concatenation is that realignment is tedious when you have to remove a sentence. And it introduces unnecessary Git noise. e.g.

msg := ""Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor " +
    "incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud " +
    "exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure " +
    "dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur."

-->

// We remove the second sentence, but now the entire code block has to be readjusted
msg := ""Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor " +
    "incididunt ut labore et dolore magna aliqua. Duis aute irure dolor in reprehenderit in " +
    "voluptate velit esse cillum dolore eu fugiat nulla pariatur."

In JavaScript/TypeScript land, the most popular linter is eslint, which is similar to lll in that it has a max-len rule. It has an ignoreStrings flag which is set to true by default - a sensible default.

The implementation for this is located here: https://github.com/eslint/eslint/blob/master/lib/rules/max-len.js#L314-L315 As you can see, it is extremely simple.

In Golang land, I think the practice of ignoring strings should also apply, for precisely the same reasons. I was curious to see if other big Go projects were breaking up long strings, so I took a look at Kubernetes, which is probably the biggest. I was only able to find one instance of concatenated strings. Instead, most code is written like like this.

Similar to eslint, is it possible to add an ignoreStrings flag to lll? Currently, I have gotten so fed up with adding //nolint: lll everywhere that I have stopped using the linter, but it is a great tool and I would love to be able to use it again in the future.

This allows users to have a longer line-length limit for code than for natural-language text.

One example is a project that wants "most" code to fit in 80 columns, but will allow the occassional long line. The best way to implement this in lll right now is to have a longer line limit (say, 100 columns) with an understanding the code-reviewers will make sure most lines are not over 80 columns. But we still want all comment lines to fit within 80 columns, since there's no good reason for them not to. This new flag allows for that.