• some guy (unregistered)

    If only. When I frist tried to get our linter to behave, I failed pretty hard. And the second time. And all the other times. It's almost like the vendors of these linters care more about pushing the new shiny thing rather than helping the end customer, strangely.

  • Hanzito (unregistered)

    Is there anyone who doesn't hate linters? I mean, there are some helpful linting rules, sure, but it seems as if you always have to disable a godawful amount of other rules to get going.

  • Daniel Orner (github)

    This is why there's been a proliferation of "standards" linters like https://standardjs.com/ and https://github.com/standardrb/standard - the idea is that it just simply does not let you make any changes to its configuration. A huge percentage of linting rules are personal preference, and you can eventually just get used to them. Obviously there are sometimes actual bugs in the linters that you need escape hatches for, but otherwise you just get the freedom of not being allowed to fine-tune or bike-shed. Not for everyone, of course.

  • (nodebb) in reply to Daniel Orner

    the idea is that it just simply does not let you make any changes to its configuration

    Sometimes the situation calls for it. For example, it's perfectly reasonable for a linter to insist that all properties are either nullable or initialized in a constructor. However, there are some cases, e.g. a class that contains unit test, where there is a setup and a one time setup method. Both are forms of initialization and the linter may not be aware that they are guaranteed to be called before the properties are accessed.

    As someone who reads a lot of diffs, I appreciate that linters enforce enough consistency so I can see what really changed. As a security guy, I can appreciate that linters help developers avoid common errors, some of which have serious security implications. But the idea of non-configurable linters sounds like a solution in search of a problem to me.

  • (nodebb)

    Let's cast all of our printf calls to void because the linter is upset that we don't use the return value!

  • 516052 (unregistered)

    Honestly that return value is just one of those things you don't even think about (or know) until the moment it suddenly comes in incredibly handy. At least in my experience. Than again, not many people have to roll their own logging framework in C these days. Thankfully.

  • Richard Brantley (unregistered)

    You can put an .editorconfig file in your project and add this line:

    csharp_style_prefer_primary_constructors = false

    But in the end, I just started writing Primary Constructors. It's easier, and modern C# developers will be used to seeing it. I find addressing the messages the analyzer produces to be a good and fast way to get up to speed on syntactical changes between versions of C#.

  • (nodebb)

    Primary constructors and the [ ] collection initialization are "recent" additions to C# and VS can get very annoying with them if you're working on large codebases, which is why the suggestions ends up disabled more often than not. We love the new sugar but we hate getting our faces pushed on it.

  • (nodebb) in reply to davethepirate

    Let's cast all of our printf calls to void because the linter is upset that we don't use the return value!

    Amen, brother. I lived through that, under a manager who insisted on a completely clean lint output. Never again.

  • Álvaro González (github)

    Linters have the perverse incentive to add as many rules as possible, because it's their biggest selling point. And it's way easier to add style rules than finding actual bugs in the codebase.

  • (nodebb)

    I feel it's worth pointing out this isn't some third-party linter; this is the default analyzer from Microsoft. Create a .NET console app in Visual Studio and add a class with a standard constructor that takes a parameter. Shortly it will give you the message to use a primary constructor. Use the Quick Actions and Refactorings to suppress it and wait for the Remove unnecessary suppression messages to show up. If you don't suppress the suppression it turns the single message into two because it marks both the disable and the restore pragma directives separately.

  • (nodebb)

    Given Remy's comments on them in the past, another .NET analyzer worth complaining about is the one for conditional expressions that want's to turn any if statement it can into a conditional/ternary. It's rare, but every now and then we have a validation method where we want super-specific formatting errors, so we might have a series of if (!condition) return/throw ... statements. It will gladly stack every one of them into a single long conditional across many lines. I find it especially interesting because I've looked at a lot of Microsoft code and haven't seen anything like that in their own code, so why do they want to force it in mine? I'd say maybe to punish early exits, but their code does have its fair share of those.

  • Loren Pechtel (unregistered)

    @OldManOfTheCSharp: not only that, but I want one test to address one objective. Same as a function should have one purpose, I only want to group tests that apply to the same thing into one statement. I have sometimes taken to using a nested function to gather up all the tests.

  • (nodebb) in reply to OldManOfTheCSharp

    I've had it suggest that I change:
    if (someCondition) { throw new SomeException(); } return someResult;

    into a ternary:
    return someCondition ? throw new SomeException() : someResult;.

    That was with the dotted underline, not the green squiggly one, so I could ignore it.

  • A.N.O Nymos (unregistered) in reply to prueg

    I've had that one. Another one I sometimes get is when using lists var someValue = someList.Where(x => someCondition).SingleOrDefault();

    if (someValue == null) throw new Exception();

    Suggestion: var someValue = someList.Where(x => someCondition).SingleOrDefault() ?? throw new Exception();

    I mean, technically they do the same, but the original is much easier to read and (if necessary) debug.

  • (nodebb)

    I recently saw the exact same thing!

  • DigitalBits (unregistered) in reply to Jaime

    Unit tests aren't the only case either, serialisation is another big one. The main one I've encountered is entity framework classes. Having non nullable properties that aren't explicitly set is perfectly valid. I believe the recommended "fix" - and the one we use - is to set it explicitly to " = null!;", essentially telling the code analysis tool to shut up.

    If you make them nullable, then they become nullable in the database, which is sometimes wrong. You can't always initialise them in the constructor, especially if you use the foreign key's ID to create them, rather than the foreign key object.

    I like linters in general, even prettier in typescript which is fairly opinionated, but with some flexibility. But I really hate darts linter, it has essentially no customisation, and forces god awful two space tabs on you, so now we have dart code that doesn't match the code style fro the rest of the organisation.

Leave a comment on “Lint Brush Off”

Log In or post as a guest

Replying to comment #696537:

Log Out

« Return to Article