• Jaloopa (unregistered)

    With this evidence about the value of linters, maybe the senior dev will listen to reason

    Well, there's a frist time for everything I suppose

  • (nodebb)

    "Senior Dev" (not that one) here.... I want every tools possible for evaluating my (and my teammates) code as possible. Attitudes like "just write better code" denies the fact that we all make mistakes.

  • (nodebb)

    Code is bad because reasons.

  • (author) in reply to TheCPUWizard

    I used to make mistakes, but I gave it up for New Years, and honestly, I don't miss it.

  • Reasonsable Lint (unregistered)

    Writing this code is not a WTF. It's a typo, and it's JS so no compiler to tell you that's invalid (indeed it isn't even invalid). And not properly writing unit tests against this kind of user facing interface code isn't really a WTF either - yes, you should, but there's almost always somewhere that that effort is better deployed in a large system.

    But how, having written that code, do you not test it and discover it's broken? Unless the anonymisation has changed it, the HTTP response will always contain the function definition, so even the most cursory manual test would show the mistake.

  • MiserableOldGit (unregistered) in reply to Reasonsable Lint

    Yes exactly, if basic unit testing is not taking place then adding in fancy automated test tools is possibly only going to give a false sense of security ... a slightly different typo could easily pass such "linting" and still be wrong.

  • Brian (unregistered) in reply to MiserableOldGit

    Obviously, no tool is going to be 100% perfect. Anyone who's lulled into a "false sense of security" from using any particular tool is obviously not very experienced in the industry. Especially things like unit tests and code reviews that require discipline from time-starved devs (and their managers) to actually implement them correctly. But having multiple layers of code-quality tools and processes does greatly reduce the possible range of mistakes that can make it through to deployment.

  • (nodebb)

    New C# lint features in VS 2019 are invaluable. Things like unused and unsigned variables, unused return values, etc (not certain which checks were added when exactly) - plus nullable reference warnings, should help programmers at every level write better code. They help me a lot.

  • Sole Purpose Of Visit (unregistered) in reply to Mr. TA

    Those features are indeed present, mostly at or before VS2009 (as I recall). Not much use for Javascript, though.

    I wouldn't even call them "lint," or "lint-like." My experiences with an actual "lint" (back in the days of C) were uniformly horrible, with a S2N ratio of roughly 0.01. It was actually easier to track things down manually ...

    And while we're on the subject of C# and VS, you'd be amazed (or not) how many programmers completely ignore the helpful wiggly green lines that represent linty behaviour. Things like "you're obscuring the inherited method call. Use new if you want to do this." Or the even more egregious "object equality applies here. Did you mean to cast the object to string [or whatever]?"

    Compared to the sluttish behaviour I have to put up with, the Senior Dev in the OP is almost bearable.


    So did the senior dev give up lint for lent?

  • MiserableOldGit (unregistered) in reply to Brian

    Agree mostly, I've just lost count of the arguments I've had with IT directors and project managers who want to buy these fancy widgets as magic bullets and refuse to consider fixing broken processes or staffing problems.

    I'd like to agree with you about that, but I've seen the opposite so many times. Well, I've seen people who should know better buy the tool thinking it would fix all their woes and then .... splat. I've also worked with (and seen) teams where they continually make bugged releases and then just look hurt and confused while waving about various scripts and reports from their testing and change management systems which say it was all fine (in spite of the outcome!).

    Nothing against a good suite of testing aids, but you still need people with common sense in control of what's going on.

  • (nodebb)

    A responsible developer uses the error-finding tools that the community spent their time writing. Programmers have been doing this for nearly fifty years and the tools keep getting better.

    BTW, this is why good developers distrust lose typing and global variables - they make code-verifying tools less helpful. The tools are improving, but the more guarantees the language makes, the more information the tools have.

    This also reflect what a mature developer demands of a language. Beginning developers worry about getting things working. Mature developers want code that is easy to understand, makes it more likely to write correct code, and has tooling that finds our mistakes.

    A true lead developer not only uses the tools, but enhances the tools to help their team comply with the unique challenges of their working environment.

  • Captain Dennis Cooper (unregistered) in reply to Reasonsable Lint

    First start with an Either. Left for error. Right for success.

    On request input, ask for a Reader of validation types: error codes, labels and functions to run. Map all validation to the Either, so users can see all the errors.

    If no errors, ask for a Reader of parse types. Map all parse to the Either. Fold into a IO of a send function.

    Of course everything is typed, so programmer mistakes are caught at compile time.

    And then throw an io library on top of everything so runtime input gets checked against static types.

    Errors are extensible. Only need to build a validation reader. Parses are extensible. Only need to build a parser reader. The boilerplate implementations of validation, parse, and send are isolated and can be swapped out if something better comes along. No loops or conditional logic.

    I wouldn't talk to other programmers. They mean nothing. I would just talk to big local boss, who knows nothing of programming, and the money guy hopefully if the big boss is listening.

    I would be cold as ice. Poker face, and state the facts about what the code does. I wouldn't even try to sell type checking or extensibility.

    When the fire me, I would just say "ok". Work up until the minute, and not let my guard down, and just give straight, one word answers.

    That would be very very funny.

  • Rakov (unregistered)

    This is a matter of naming conventions. Things should be named in a way that shows what they are. E g, a library should be called LibReasons or ReasonsLib.

  • Prime Mover (unregistered)

    Lint, schmint, getting your devs to make sure they attend to all the warnings the IDE throws up would be a miracle.

    I gave up trying to get my colleagues and mentees to actually run the available verification tools on the code they wrote.

    I'm convinced that if only engineers would at least make a token attempt to read the warnings and at least understand why they're there, then the quality of code would improve greatly.

    "Oh, but I haven't got time to check it, I've got stuff to implement." Sorry, sunshine, but if you can't be bothered to clean your shitty-arse code, we can't be bothered to pay you. Don't let the door hit you on your arse on the way out.

  • (nodebb) in reply to Prime Mover


    Not that I disagree with you in general, but the IDE warnings are simply another form of linter. So, yes, it would be awesome of most developers would look at the lint output and either address it or suppress it (so we can pay attention to new stuff).

    I had a week long fight with a developer over whether he had to use SQL-injection prevention in his code (in 2019). He felt his code was being deployed is a way that there wasn't enough risk to worry about it. The worst part was that he didn't even know how to address it, so he was fighting me because he didn't want to figure it out.

  • (nodebb) in reply to Jaime

    I wish it were possible to enforce "fix warnings" on a build-pipeline level.

    I mean, you can make the pipeline reject code, that isn't warning-free. But then you'd have either weird workarounds to avoid spurious warnings, if they cannot be suppressed, or otherwise the warning equivalent of try { fail(); } catch { /ignore/ }.

    The only real fix is probably a corporate culture that takes warnings seriously, and that rejects patch-jobs in favor of occasionally not delivering a feature within a deadline. (Or at least marks it as a "beta feature" and accepts, that the end user should KNOW that they can't expect stability yet, if they have to use it.)

    Sadly not unrelated: In our build-pipeline even static checking of function interfaces is undermined. Many function do not user header files, and are instead called as external routines, so we have a statically compiled language, yet code may crash at runtime because two files didn't agree on type and/or number of the arguments of a function. Which for functions with 10+ parameters can easily happen... It also means, that a typo in a function name will not be noticed at compile-time of the individual file, but only in the final linking step. Yay for thisIsNtATypo();.

  • Just_no (unregistered)

    Why use a linter when a compiler could have found the problem for you? Static typing is almost always better than dynamic typing.

  • (nodebb) in reply to Jaime
    good developers distrust lose typing

    Congrats on the first to reverse-mistake lose/loose !

Leave a comment on “Reasonable Lint”

Log In or post as a guest

Replying to comment #:

« Return to Article