ShortN0te comments on Shiiieeettt.......

[–] ShortN0te@lemmy.ml 72 points 2 years ago (2 children)

A lot of IDEs would probably throw a warning about unreachable code.

parent

[–] bus_factor@lemmy.world 25 points 2 years ago (1 child)

Golang won't even compile with dead code. Unfortunately that's too strict, you just end up commenting out the whole block instead. At least the commented out code is obvious in review, and some automated checks catch it if you have them.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] ramjambamalam@lemmy.ca 3 points 2 years ago

commenting out the whole block

var foo is declared but not used is such a pain in my asshole when doing this.

permalink

fedilink

source

parent

[–] Pyroglyph@lemmy.world 13 points 2 years ago (1 child)

implying that any developer actually reads warnings

permalink

fedilink

source

parent

hideshow 2 child comments

[–] vox@sopuli.xyz 14 points 2 years ago* (1 child)

most of my (rust) projects have zero (or maybe 1-2) warnings, unless I'm in the middle of working on a feature

permalink

fedilink

source

parent

hideshow 2 child comments

[–] micka190@lemmy.world 24 points 2 years ago (4 children)

First thing I do on my projects is enable warnings as errors and increase my warning levels when reasonable.

Unfortunately, the same can't be said on the projects I work on at work. Drives me crazy that we get likes 300+ warnings whenever we run the app and that we can't change it because "they're just warnings*.

permalink

fedilink

source

parent

hideshow 8 child comments

[–] Alexstarfire@lemmy.world 8 points 2 years ago (1 child)

🤢 Good lord.

Though, I say that as I was basically forced to accept code that was using something marked deprecated because it was unreasonable to refactoring the code in that project. And I know we're never going to change it unless it stops working. 😭 At least I marked it as an issue on the review.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] micka190@lemmy.world 9 points 2 years ago

Oh yeah, I'm genuinely about to hand-in my resignation as soon as I find another job over this kind of shit. I keep being told that the business is really trying to clean-up its act when it comes to coding practices, but they keep putting some of the most incompetent people I've ever worked with in charge of shit (because they do promotions based on years of experience instead of actual actionable experience). It's awful.

permalink

fedilink

source

parent

[–] PoolloverNathan@programming.dev 7 points 2 years ago

That's when you add #![deny(bad_code)], making sure that nobody notices.

permalink

fedilink

source

parent

[–] Potatos_are_not_friends@lemmy.world 5 points 2 years ago (1 child)

It's not that we want to ignore warnings. It's just that most warnings take time to fix.

There's only so many hours in a day. And we have to accept technical debt in order to deliver, and then pay it off later.

My job does it well by doing a "spring" and "summer" cleaning where we can turn out 100+ warnings into the single digits. Then busy season happens again and we're back to 200+.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] micka190@lemmy.world 3 points 2 years ago

It’s not that we want to ignore warnings.

Speak for yourself, I promise you the team I work on actively ignores warnings and doesn't even want to solve them as they pop-up. Being told you can't compare doubles (because of precision loss) and ignoring it is on the developer and isn't even that hard to fix. Most of our warnings come from shit like that.

Like, I get it. It's probably not worth it to hunt down every "unused variable" warning (especially in an API where we used to have a variable for it and we don't use it anymore and we don't want to break the existing API so we just leave it there), but there's things that are just trivial to fix when you're working on code that's right next to it.

permalink

fedilink

source

parent