Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
This is exactly the problem with this experience thing in coding. You can write crappy code for 9 years and be preferred over someone who writes clean code for 2 years. Years on the job is a very poor indicator for programming skill.
And by the way, initiating an empty variable to return it instead of returning from the conditional is just shit code.
Did I just hijack the rant? -
Its unbelievable, but I had this same discussion with s colleague of mine. He's a young dev and quite smart but once U saw him returning after a throw and I told him the execution is not going to reach it because throwing cancels the execution too and his response was "yeah, but you can't be sure, what if it doesn't?"...
Im like... Bitch... I've worked with this shit for way longer than you. I know what Im talking about...
I think the problem is that they don't understand try/catch blocks and they sometimes see the code continues and sometimes don't and its somehow confusing for inexperienced devs even if they write it every day -
@Hazarth Tell him to screw his chair to the floor and add a seat belt, gravity holds things to the ground, but what if it doesn't?
-
@netikras in c# is "just" a warning (by default)
-
Your taste for
if(condition) {
return foo;
}
return bar;
I saw some crazy things in JavaScript/Typescript with this style. Especially if the condition is reliant on a callback or an await and you don’t realize it. There is a situation where the ”if” gets skipped because the condition is unresolved. The function then returns bar. When you put the second return in an “else” and the function can’t return until the async/callback is done.
We used to stumble across it when using Mongoose. We never determined exactly what happened because deadlines but switching to the second style prevented it so we all switched to avoid it. -
@dozingncoding I find that “safety patterns” make their way back to other languages as well when I’m in the other parts of the stack I don’t have to change coding style as much.
I have had people complain about styles and it is because I’m trying to make a habit somewhere else in the stack they don’t go so used it in a place where it doesn’t matter. Usually the further towards metal one goes the less those things matter. My JS definitely influences my C#. -
Seems bad... but I have a minor twinge of doubt that perhaps it's due to a horrible static code scanner - earlier, if not now. It is so difficult to get people to NOT do what the scanner suggests when it gets out of date or is just wrong. I would totally believe Fortify having a fit for 'no return' from a branch.
Related Rants
I like my new USB enter key.
This customer's dev is going to be the end of me. I had to explain to him why it doesn't make any sense to return a value after throwing an exception.
In a function that was supposed to insert a record amd return its id, in the error handling code:
catch(Exception ex) {
//logs the exception
throw ex;
return - 999; //this code will NEVER be reached, and why the f.... - 999?
}
The customer wants us to develop the project together, but he won't listen and always write whatever he wants. Some might be differences in taste. Like me preferring
if(condition) {
return a;
}
return b;
And him preferring :
Foo result = null;
if(condition) {
result = a;
} else {
result = b;
}
return result;
Ok, that I can accept. But things like the one I'm ranting about... I wont.
I'm starting to wonder what was he doing during his "9 years of coding experience"
rant
notthathard
ffs
throw
return