Stop aligning struct tags when length difference exceeds threshold

[lrstanley]

I have generally always manually grouped struct tags based on a few common patterns, some of which are similar to this linter (sorting, specific tags first, etc). However, when it comes to adding alignment and padding, I've always taken a different approach. For example:

In the above example, I'm doing a couple of things.

1. If some fields have a tag, but others don't, it's no longer aligned and/or the alignment is based off a completely different column.
2. If the "next" alignment option leads to a very large empty space/super long line, alignment no longer happens. This ensures some kind of balance between alignment, and having a bunch of line wrapping with empty space.

It seems like the fall-through approach for 1 is currently supported when strict: false, however, there is no "give up when the length is above a certain size" kind of approach. Would you be open to something like this? e.g. if the alignment is different between two of the same, or different, tags is above X amount, no longer try and align. This could default to 0 to not impact users.

I'd like to avoid these scenarios (where the vertical lines are my typical "ruler" length for how long my lines should be):

Another example with sort: true and align: true:

vs a combo of alignment + "this field is super long, just don't bother aligning anything after X length"

I'm not set on the approach (single field length difference vs "don't sort after X characters" (for the entire struct tag).

[4meepo]

We can add a new option StopAlignThreshold which default to 0.

This configuration option specifies the maximum allowable length difference between struct tags in the same column before alignment stops. When the difference between the longest and shortest tags exceeds this threshold, the alignment for subsequent tags in that column will be disabled, while the preceding tags will remain aligned. This helps maintain readability without creating large gaps.

Would this approach meet your needs, or do you have any suggestions for improvement?

[lrstanley]

I believe that would, yep!

[4meepo]

@lrstanley My code is ready. Could you please provide me with some code so you can preview it before I merge these changes to golangci-lint.

If that's not what you want, we can still make changes.