- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Well, there's a frist time for everything I suppose
Admin
"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.
Admin
Code is bad because reasons.
Admin
I used to make mistakes, but I gave it up for New Years, and honestly, I don't miss it.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
So did the senior dev give up lint for lent?
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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();.Admin
Why use a linter when a compiler could have found the problem for you? Static typing is almost always better than dynamic typing.
Admin
Congrats on the first to reverse-mistake lose/loose !
Admin
Any normal language would have pointed out that the variable was written to, but never read.
Admin
I'm astonished at all of the other comments here. You seem to be the only one who understands. It's not about tools or programming practices, it's about the most basic parts of the job. RFC 1925.2.1. It has to work. For any unfamiliar with this important RFC, section 1 is the introduction, so this is the very first thing of relevance in the document.
This having been said, early in my career, I was very frustrated with the number of 'senior devs' who claimed that output that occurred from their web pages every time could not possibly happen, and so spent no time in looking into it.
To be fair, these were all people over the age of 50 who had been working in the industry (and most of them at that same company) for upwards of 20 years.
Eventually, one of these people sought other opportunities elsewhere. I never heard whether their seeking of those opportunities started before or after I was informed of this. I was just told that it was his last day, I wasn't supposed to contact him about anything as he was going to be "busy" with other things all day, but here was a copy of his code for various websites that he "supported" that never worked, and would I see if I could fix it. "It'll take a day or two to give you access to the systems, so just work on your own machine for now."
That all read to me like he was fired and not in a small way, but I really don't know. Anyway, it was full of stuff I'd have been tempted to post here if I'd known about this site. It was clear that he never tested any of this stuff at all.
I'd been a contractor at the time. When I got a job offer for the same position as an employee, I was not too surprised to see I was titled a senior dev, despite being about 20 years younger than any of the other senior devs.