A rant
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerUgh. I'm doing some refactoring on bad code right now (not by choice). I was asked to add a feature to a windows service (a "quick fix"); it's now day 2 & I've rewritten about 50% of it. Very few comments, best one is at the WTF point- 'Remove table with parameters. 'It is done to addapt dataset for later routines which really means, make sure I've only got 1 datatable so I can hardcode it everywhere else. example- 'Count number of tables in dataset Dim countTables As Integer = 1 good times.
-
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerMarc Clifton wrote:
I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way?
Yes. It's like having to sniff someone else's farts... X|
-- Not Y3K Compliant
-
I go through this everyday. The project I am working on was put together by a few developers that just had the attitude of get it working and worry about the rest later. The management throws around the word refactor for everything. They always say oh we will just refactor it later. Well the crap code piled up so high that it started causing hugh problems. They built it with out a solid design, commented nothing and they copied and pasted the same code in multiple classes all of the places, tons of hard coding and no oo design (they had no idea how to use inheritance or polymorphism). My initial roll on the team as the junior developer was to just help the senor guys out. Well 6 months later they fired both senor guys because everything they wrote started to break and I am stuck writing in this mess all day long. Its so bad I really don't like having my name associated with the mess. I go home sick to my stomach some days. Not to mention that sometimes I feel like I am not learning anything and I am starting to become a worse developer because of this mess. So after my rant I would say yes bad uncommented simple code leads to bad uncommented compiled code.
BrockVnm wrote:
The project I am working on was put together by a few developers that just had the attitude of get it working and worry about the rest later. The management throws around the word refactor for everything. They always say oh we will just refactor it later. Well the crap code piled up so high that it started causing hugh problems. They built it with out a solid design, commented nothing and they copied and pasted the same code in multiple classes all of the places, tons of hard coding and no oo design (they had no idea how to use inheritance or polymorphism). My initial roll on the team as the junior developer was to just help the senor guys out. Well 6 months later they fired both senor guys because everything they wrote started to break and I am stuck writing in this mess all day long. Its so bad I really don't like having my name associated with the mess.
Geez, that sounds exactly like what I'm dealing with. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer -
Marc Clifton wrote:
Looking at bad code makes me cringe.
Standard practice in my case. I'm a contractor and typically do a lot of maintenance programming. Maintaining bad code is the norm.
Marc Clifton wrote:
if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code?
Recently had to do post hoc unit testing on a complex piece of software that had virtually no comments, and the few it did have were pretty useless.
Marc Clifton wrote:
Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with?
There are different types of refactoring. 1. Refactoring code because it's bad. 2. Refactoring while writing it. 3. Refactoring for extension. Maybe others... Only the first is an undesirable situation. However, I think that's what you mean?
Kevin
Kevin McFarlane wrote:
Only the first is an undesirable situation. However, I think that's what you mean?
Yes, that's what I mean. Because #2 doesn't happen, even when the compiler screams warnings. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer -
Looking at bad code makes me cringe. When I look at something like a simple function that returns a string and the compiler warns about unreachable code detected and the code itself has multiple return points, I can't help but wonder, if simple code like this is so poorly implemented, warnings aren't fixed, and there's not comment to explain what the if statements and switch statements are even doing, what can I expect in complicated code? I have this visceral emotional reaction to bad code, it makes me not even want to touch the whole project, even if I'm working on an isolated part of it. I'm still associated with the bad code. Do you ever feel that way? Or am I letting my emotions get in the way here? And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO. How much refactoring could be eliminated if you just wrote the code right to begin with? And come now, does refactoring really happen? It's more like a meditation than a practice. What's the sound of one programmer refactoring? Yeah, exactly. Shouldn't code get reviewed frequently, even in the midst of a the continuous fire drill? I mean, after all, if you acknowledge that the fire alarm is always sounding, then you might as well figure out how to do the programming better and smarter, rather than take the McGyver approach and hope the ducttape lasts to end of the episode. Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later? About that lying questionnaire below, good intents are almost like lies, but you're never actually caught at the lie because you can always say "it'll happen soon." So, is there some truth my conception that bad, uncommented simple code is a portent of bad, uncommented complicated code? And is there some merit to the conclusion that the bad, uncommented, complicated code will also be really buggy? Is there some merit to the attitude that refactoring should be minimized? What are your thoughts? Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerI call it code slamming - generally. Then there is the code clearly written by someone who has no passion for the quality of their product.
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Refactoring is about altering the structure of code/designs to accomodate new requirements (aka features, performance, etc.) It is not about making code "good." Code should always be good, if not fantastic. People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming.
:josh: My WPF Blog[^]
Josh Smith wrote:
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming.
Quoted! (poor Jorgen, I had to bump his quote off). Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Cotter wrote:
A systemic lack of comments and indicators like multiple return points
What do you have against multiple return points? What's wrong with this?
public int Foo
{
get
{
if( muck )
return 0;
return 42;
}
}:josh: My WPF Blog[^]
Josh Smith wrote:
What do you have against multiple return points?
Multiple return points when the logic is simple makes code more difficult to understand at a glance and to maintain. All too often I've added some functionality only to discover that there's a return statement I didn't notice earlier in the logic. This is not to say that I'm religious about it, I'm just conscious about the issue and make the decision based on code complexity. Here's the code that started this thread (obfuscated to protect the guilty):
public string Foo { get { switch (SomeType) { case TypeA: if (bar == null) { return null; } else { return bar.MyId.ToString(); } break; case TypeB: if (snafu == null) { return null; } else { return snafu.MyId.ToString(); } break; } return null; } set { q = value; } }There are so many things wrong with code, it's a perfect case study of bad programming. 1: the setter is setting something different than the getter. Since this is unusual practice, put a comment as to why 2: the getter is testing for null objects. Shouldn't this rather throw an exception if the object isn't initialized, but the object type is? 3: shouldn't there have been a flag raised when implementing that the object type is being decoupled from the object itself (see #6) 4: breaks never occur because of the returns 5: returns instead of a single return point 6: Since both types convert an ID to a string, why not create an abstract class or an interface so that container class maintains the interfaced instance and you can get the ID without the switch statement? 7: use to the ToString() method or have the object convert the ID itself to string, ie. GetIDAsString(), which is more flexible if later on, you want to do something different with the ID, like hash it, or whatever. So in these very few
-
if(!connect()) return false; //continue with processing return true; That's a lot cleaner than bool ret = connect(); if(ret) { //continue with processing } return ret; And it saves a level of indenting. Maybe with 1280 x 1028 resolution this isn't such a big deal, but I still say there's nothing wrong with this style. Its just that, style.
This statement is false.
Chris S Kaiser wrote:
That's a lot cleaner than
Actually, I'll disagree. Ironically, you'll see exactly your example of "not cleaner" in my code. And the reason is because at some point, I actually needed to code an else statement when connection failed, which didn't require my having to check if there's a return statement earlier. Trivial example, but still. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
IMO, refactoring has to happen. Even if you wrote code the right way to begin with, requirements change. When requirements change, your code architecture has to change to reflect that. Often times, that's where refactoring comes in for us.
Marc Clifton wrote:
And come now, does refactoring really happen?
Absolutely. I do a little everyday at work.
Marc Clifton wrote:
Does your team ducttape (I always thought it was duck tape) the code and promise each other to refactor later?
We refactor when it's needed. I think the only exception is large refactors that would takes many, many months to complete. For example, after working in the same codebase for 2 years, we've recently started using test driven development. Much of our code up to this point wasn't designed with testing in mind, so if we really want to test a piece of code, it often has to be refactored. UI code is a big example here: I now see that most of the logic in our UI code simply cannot be tested because it's too intertwined with the UI code. So we've started to use the MVP pattern to seperate the logic and the UI code, thus allowing us to test the logic of the UI without getting entangled in UI code. But to take a timeout and refactor our hundreds of controls and forms to use the MVP pattern with unit testing would just be too huge a refactor. We simply don't have time to spend a couple months to do this. Instead, I'm migrating pieces at a time. Also, all new pieces use the MVP pattern with unit testing. So the code migrates over time. Besides the rare huge refactoring like that (maybe refactor isn't even the right word in that scenario), we do smaller refactors often, every day. Pulling interfaces out of classes, having consuming classes use interfaces (which can be mocked in unit testing) instead of concrete classes, renaming classes and namespaces to better reflect their usage (again, things evolve), making things simpler, the list goes on. In that sense, we refactor all the time. p.s. By the way Marc, [happy birthday](http://judahhimango.com/music/the beatles - birthday.mp3)[[^](http://judahhimango.com/music/the beatles - birthday.mp3)] man! Have a great, happy birthday weekend. :cool:
Tech, life, family, faith: Give me a visit. I
Judah Himango wrote:
Much of our code up to this point wasn't designed with testing in mind, so if we really want to test a piece of code, it often has to be refactored.
That kind of refactoring, sure I'm fine with that. But the "I'll refactor the compiler warnings later" problem, hmmm. And I can understand refactoring architecture to add features, improve testing, etc. I don't agree with putting off even minimal thinking about architecture and "we'll refactor that later". Some things ought be done more or less right, with the knowledge available at the time, and not just "coded".
Judah Himango wrote:
Have a great, happy birthday weekend.
:-D Thanks! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Yes crap code happens every day. Why... lots of reasons, like crap developers (spend some time in the forums) and crap managers and crap companies.
Marc Clifton wrote:
And then I hear the "we need to get something out, and we'll refactor it later". Refactoring is abused, IMO.
Refactoring "should" occur when the design must change due to an analysis error or requirement change, not as an excuse to do crap work originally. And all of this is under the guise of "it's faster", which in my experience has never proven to be true, it's all bullshit. Anyway you don't need to believe me, see the web for Technical Debt[^]
led mike
led mike wrote:
Refactoring "should" occur when the design must change due to an analysis error or requirement change, not as an excuse to do crap work originally. And all of this is under the guise of "it's faster", which in my experience has never proven to be true, it's all bullsh*t. Anyway you don't need to believe me, see the web for Technical Debt[^]
Oh I believe you. And thank you for the link. It's great writeup. Short and to the point. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
The similar circumstances that I see all too often is "we'll skip unit testing because of time pressure and catch all the errors in integration". Firstly the project will never catch up and second the integration will take longer without unit tests. I once did a phase review on a project where the manager had just decreed that no more unit testing or code reviews would happen in order to keep on schedule. My report stated that I considered that too risky. However, the project manager asked if it were certain that integration would take longer than scheduled and I had to say no, but it was high risk. He went ahead anyway. Guess what - integration took much, much longer than scheduled because of all the bugs they had to fix. :sigh: I didn't get much satisfaction from being proved right. I did the analysis and the extra time spent in integration was more than the time saved in unit testing and code reviews. So yes, code should be reviewed frequently even in the midst of the continuous fire drill. Bad code will bite you (or someone else) in the end. As for refactoring, my initial reaction was yes I do it all the time. But reading other replies I realised that I do it as part of the natural development process when writing the code in the first place or because I'm changing a piece of old code because it now needs to meet new requirements and it's architecture is no longer sufficient. I cannot think of any time when the code has been refactored just because it is messy.
Graham My signature is not black, just a very, very dark blue
Graham Shanks wrote:
The similar circumstances that I see all too often is "we'll skip unit testing because of time pressure and catch all the errors in integration". Firstly the project will never catch up and second the integration will take longer without unit tests.
Yup. I've got a situation where the following has been said: "we'll refactor in the unit tests when we've shipped the first version of the product." :laugh: :(( :laugh: :(( Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I call it code slamming - generally. Then there is the code clearly written by someone who has no passion for the quality of their product.
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
charlieg wrote:
I call it code slamming
That's a great phrase! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Kevin McFarlane wrote:
Only the first is an undesirable situation. However, I think that's what you mean?
Yes, that's what I mean. Because #2 doesn't happen, even when the compiler screams warnings. Marc
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmerSurely 2 does happen? Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Kevin
-
if(!connect()) return false; //continue with processing return true; That's a lot cleaner than bool ret = connect(); if(ret) { //continue with processing } return ret; And it saves a level of indenting. Maybe with 1280 x 1028 resolution this isn't such a big deal, but I still say there's nothing wrong with this style. Its just that, style.
This statement is false.
I generally aim for the single return but not religiously. I think in the case you mention where you have a return false at the top and then a single return at the bottom that's fine. Any other multiple return sceanrio is to be avoided. It's not such a big issue when methods are short, which they're supposed to be in good OO. But most programmers seem unable to write sufficiently short methods. Then multiple returns become a menace.
Kevin
-
charlieg wrote:
I call it code slamming
That's a great phrase! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithYeah, it tends to fit too. Analogy is "mule marks" in carpentry. This is where you miss the nail and leave a dent in the wood. Why mule marks? Because only an ass would make them... Geeze, I'm feisty today. I posted a rant in Dell's support forums, and they deleted it. Seems I put too much #$%#$^%$^ in the forum for their taste (it was all directed at Dell). Mistakes I can handle but making part of your process, pisses me off. Anyway, back to the code - the problem with code slamming, errr, it isn't good, everyone forgets the schedule pressures, so don't be *too* hard on the developer. There is usually more than enough blame to sling even though I would argue that one should get better at code slamming with more practice :mad:
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Surely 2 does happen? Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Kevin
Kevin McFarlane wrote:
Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Kevin McFarlane wrote:
Don't you ever write a method, get it working then go back and tidy it up - rename, extract methods, etc? Or do you mean that you do this yourself but most others don't?
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Sure I do, but yes, it seems that on this project I'm helping out on, others are not doing that.
Seems to be the norm I'm afraid. It's rare that I maintain code that shows any courtesy to the maintenance programmer. :mad:
Kevin
-
Yeah, it tends to fit too. Analogy is "mule marks" in carpentry. This is where you miss the nail and leave a dent in the wood. Why mule marks? Because only an ass would make them... Geeze, I'm feisty today. I posted a rant in Dell's support forums, and they deleted it. Seems I put too much #$%#$^%$^ in the forum for their taste (it was all directed at Dell). Mistakes I can handle but making part of your process, pisses me off. Anyway, back to the code - the problem with code slamming, errr, it isn't good, everyone forgets the schedule pressures, so don't be *too* hard on the developer. There is usually more than enough blame to sling even though I would argue that one should get better at code slamming with more practice :mad:
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
charlieg wrote:
the problem with code slamming,
LOL! I thought you meant that as a phrase for how coding is done, not how code is criticized.
charlieg wrote:
everyone forgets the schedule pressures, so don't be *too* hard on the developer.
True, but somewhere there's the line between doing something to save time and doing something, erm, dumb. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
charlieg wrote:
the problem with code slamming,
LOL! I thought you meant that as a phrase for how coding is done, not how code is criticized.
charlieg wrote:
everyone forgets the schedule pressures, so don't be *too* hard on the developer.
True, but somewhere there's the line between doing something to save time and doing something, erm, dumb. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smithoh this is priceless :) I *do* mean how coding is done :doh: the fact that it might be interpreted either way makes it that much funnier...
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams
-
Chris S Kaiser wrote:
That's a lot cleaner than
Actually, I'll disagree. Ironically, you'll see exactly your example of "not cleaner" in my code. And the reason is because at some point, I actually needed to code an else statement when connection failed, which didn't require my having to check if there's a return statement earlier. Trivial example, but still. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithYeah, it was a trivial example. I've had to work on code where the method isn't broken out into multiple methods, and the ret val has to be checked again and again for validity for further processing. Which could get deep with regard to if blocks. So really I use it in the case where I didn't use exception handling. So the "correct" method in my case would be to throw an exception, but for some stuff I just return instead. But I don't think its a valid representation of a senior developer that doesn't care enough. Its situational.
This statement is false.