• oppeto (unregistered)

    The secret to looking important is refactoring. Obviously.

  • A nony mouse... (unregistered) in reply to oppeto

    Obviously the problem is with the Code Review Process...Seeing such an artifact ONCE should have put an immediate stop to it. Having it pervade the codebase is TRWTF, and firmly at the leaders door!

  • Oslo (unregistered)

    Obvious obviously is obvious

  • Migala (unregistered) in reply to A nony mouse...
    A nony mouse...:
    Obviously the problem is with the Code Review Process...Seeing such an artifact ONCE should have put an immediate stop to it. Having it pervade the codebase is TRWTF, and firmly at the leaders door!

    Obviously he's using the word obviously so much so he won't be asked to explain himself.

  • ideo (unregistered) in reply to A nony mouse...

    Taran obviously had lots of check-ins and many lines of code, so boss was tricked into thinking the other team members were obviously lazy bums.

  • Luctus (unregistered)

    Obviously now Taran will refactor his resume!

  • chreng (unregistered)

    Obviously: Taran got away doing this one time for a year, he could easily do this 40 times more, with full salary, and then retire!

    I think his name really is Taddam!

  • Warren (unregistered)

    Obviously I was expecting TL to get the boot as Taran obviously knew what he was doing

  • Ylsuoivbo (unregistered)

    Obviously, the 12th of each month is "refactor day" for Taran.

  • ZoomST (unregistered) in reply to A nony mouse...
    A nony mouse...:
    Obviously the problem is with the Code Review Process...Seeing such an artifact ONCE should have put an immediate stop to it. Having it pervade the codebase is TRWTF, and firmly at the leaders door!
    //Obviously refactoring...
//Taran: the gc will take care of all of you, obviously.
//ANM: Refactoring this is as useful as
//an assembler statement in a Java code snippet.
Problem:
  Code review();
  Obviously;
  if such an artifact
    immediate stop();
    Obviously;
  if it pervade the codebase
    TRWTF();
    at the leaders doors!;
    Obviously;
Obviously!;
  • ZoomST (unregistered) in reply to chreng
    chreng:
    Obviously: Taran got away doing this one time for a year, he could easily do this 40 times more, with full salary, and then retire!

    I think his name really is Taddam!

    Or Ta-dah!

  • Inhibeo (unregistered)

    It's obviously that Taran should have sprinkled some "regression" fixes into his "refactoring" work.

  • (cs)

    I rank the 'Obviously' people in the same group as those who keep saying 'clearly'.

  • (cs)

    This is what happens when people take refactoring and patterns a bit TOO seriously. Sure, patterns are great things, but not when you put them everywhere just because they're patterns and so MUST be better than everything else.

  • moz (unregistered) in reply to MoSlo
    MoSlo:
    I rank the 'Obviously' people in the same group as those who keep saying 'clearly'.
    I will, of course, know much care I should take to avoid encountering you, based on this comment.

    I'm just wondering what this "OP" guy thinks of T. L.'s work.

  • Kuli (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    This is what happens when people take refactoring and patterns a bit TOO seriously. Sure, patterns are great things, but not when you put them everywhere just because they're patterns and so MUST be better than everything else.

    The code had obviously nothing to do with patterns.

  • trololo (unregistered)

    for all my Romanian speaking folks out there ... don't you ever program like a Ţāran.

  • (cs) in reply to Kuli
    Kuli:
    ObiWayneKenobi:
    This is what happens when people take refactoring and patterns a bit TOO seriously. Sure, patterns are great things, but not when you put them everywhere just because they're patterns and so MUST be better than everything else.

    The code had obviously nothing to do with patterns.

    Sure it did, just the wrong kind. Taran refactored at least one thing from a standard function call to a Factory.

  • A Reader (unregistered) in reply to oppeto
    oppeto:
    The secret to looking important is refactoring. Obviously.
    That's weird, to most people (and/or managers) 'refactoring' means you don't have enough work to do.
  • Pista (unregistered) in reply to trololo
    trololo:
    for all my Romanian speaking folks out there ... don't you ever program like a Ţāran.

    +1

  • faoileag (unregistered)

    The 

    for (int i=0; i<1000000; i++) {
Map<String,Integer> map = new HashMap<String,Integer>();
}
    bit is great. Still, the end comes a bit as a surprise. I expected T.L. to get the boot for questioning the wisdom of Tarans refactorings.

    Good to know that every once in a while justice prevails.

  • kartoffel (unregistered) in reply to trololo
    trololo:
    for all my Romanian speaking folks out there ... don't you ever program like a Ţāran.

    Romanian English Dictionary (MF) rookie;hick;peasant;ploughman;villager

    Indeed. No need to program like a ploughman. Obviously.

  • (cs)

    A happy ending? I smell a rat.

    And guys, it was obv... to be expected that a lot of jokes were going to be made about the word "obviously", but obv... cle... evidently, it has run thin now.

  • (cs) in reply to faoileag
    faoileag:
    Good to know that every once in a while justice prevails.
    There is always a part of the story that is made up. Sometimes it's the name, sometimes it's a unicorn, but usually it is the ending...
  • Wrexham (unregistered) in reply to moz
    moz:
    I will, of course, know much care I should take to avoid encountering you, based on this comment.
    Pardon? I assume that there's a typo in this sentence, but I've absolutely no idea what it was meant to say.
  • faoileag (unregistered) in reply to TGV
    TGV:
    faoileag:
    Good to know that every once in a while justice prevails.
    There is always a part of the story that is made up. Sometimes it's the name, sometimes it's a unicorn, but usually it is the ending...
    Now disillusion has hit me like a derailed TGV!

    SCNR

  • (cs) in reply to MoSlo
    MoSlo:
    I rank the 'Obviously' people in the same group as those who keep saying 'clearly'.

    Clearly, these people are obviously the same.

  • Smug Unix User (unregistered)

    Maybe just explain to Taran what he was doing wrong in a code review and then let him adjust his ivory tower coding. He appears to be at least familiar with the code base and switching team members has its cost. If a developer is willing to learn it is usually cheaper to keep him than hiring a new person.

  • vt_mruhlin (unregistered)

    And today it seems appropriate that I tell the tale of the micro managing boss who changed

    if(foo == null){
   return;
}

    to

    if(foo.Equals(null)){
    return;
}

    on my behalf, then called me at 2 in the morning when "my" code was blowing up.

  • anonymous (unregistered)

    Can anyone explain the utility of a HashMap that only holds one thing?

  • faoileag (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    And today it seems appropriate that I tell the tale of the micro managing boss who changed 
    if(foo == null){
   return;
}

    to

    if(foo.Equals(null)){
    return;
}

    on my behalf, then called me at 2 in the morning when "my" code was blowing up.

    +1!

  • Swedish tard (unregistered) in reply to A Reader
    A Reader:
    oppeto:
    The secret to looking important is refactoring. Obviously.
    That's weird, to most people (and/or managers) 'refactoring' means you don't have enough work to do.

    Call it something else, such as "Performance optimization"... (Sprinkle generously with technobabble if asked to specify what kind of optimisation.)

    This method of deception should be reserved for the nincompoop managers, the ones that get in the way of development due to their cluelessness of the work they are supposedly managing. Good managers can often understand the need for refactoring if explained properly.

    And the meh type of managers you deal with by simply rolling refactoring into the original time estimates for every time you touch the code. Since you should be doing it anyways. Just dont specify it as refactoring, unless for some god abandoned reason it is a measuring item for performance... In which case, you are completely screwed.

  • jaffa creole (unregistered)

    Maybe If I can find it when I get into the office I'll dig up the source to InlineReplacingTextWriter, the behemoth that a Taran-equivalent at my company used to replace a single call to String.Replace.

    The core of the algorithm looked something like this.

    private StringBuilder _matchBuilder;
public void WriteLine(string line){
    foreach(var c in line){
        _matchBuilder.Append(c);
        if(!_patternToMatch.StartsWith(_matchBuilder)){
            // this character didn't match, so create a new buffer to start over.
            _matchBuilder = new StringBuilder();
        }
        else if(_patternToMatch.Equals(_matchBuilder){
            _out.Write(_replaceWith);
        }
    }
}

    Bonus: He wanted to make sure it worked everywhere, so added an OnBeginRequest event handler in global.asax that wrapped the response's output stream in this.
    99.9% of all characters returned by our web server had to create a new StringBuilder on their way out.

  • Swedish tard (unregistered)

    People using obviously all the time are generally just performing the service of telling everyone around them that they are oblivious, but getting it wrong... Obliviously...

  • kingsnake (unregistered)

    "the best there was, is, and ever will be"

    Sorry, Taran, that would be Bret "the Hitman" Hart ...

  • nobody (unregistered)

    Snoofle,

    Your writing continues to improve (though the 'obvious' red herring was unnecessary). What happened? Did you actually take a class? Did someone else take your username? Did you stop following lame instructions from others to wildly embellish? Did you start taking supervisor's advice to stop wildly embellishing?

  • faoileag (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    And today it seems appropriate that I tell the tale of the micro managing boss who changed...
    Actually, that made me remember a tale about coding rules.

    A long time ago, a coding rule was set up that said that in C# ShowDialog() was the wrong way of doing things and that in its place, ShowDialog(IWin32Window owner) was to be called.

    Now instead of just issuing the coding rule as a directive for future use, a developer was tasked with replacing every single ShowDialog() call with a ShowDialog(IWin32Window owner).

    This broke the code in a couple of places.

    On some occassions because the developer never checked whether or not ShowDialog() had been overloaded and if that was the case, if ShowDialog(IWin32Window owner) had been overloaded as well.

    And on other occasions because the developer just simply added what he thought might make a good owner window, in one case adding the form itself as its own owner.

    "Coding Rules" are a nice thing to have, but enforcing them retrospectively might sometimes make things worse instead of better.

  • xing (unregistered) in reply to Smug Unix User
    Smug Unix User:
    Maybe just explain to Taran what he was doing wrong in a code review and then let him adjust his ivory tower coding. He appears to be at least familiar with the code base and switching team members has its cost. If a developer is willing to learn it is usually cheaper to keep him than hiring a new person.

    A developer willing to learn won't write code like that. It's much cheaper to fire the incompetent ones and hire competent ones than trying to educate them - also they should have done their training before holding a job.

  • Pista (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    And today it seems appropriate that I tell the tale of the micro managing boss who changed 
    if(foo == null){
   return;
}

    to

    if(foo.Equals(null)){
    return;
}

    on my behalf, then called me at 2 in the morning when "my" code was blowing up.

    Your boss seems to be like this guy: http://thedailywtf.com/Articles/SkillsEquals%28null%29.aspx

  • Occam's Strop (unregistered)

    Why did the original clear the map one million times? The reason is not obvious to me

    captcha: enim, therefore, but therefore what?

  • (cs) in reply to anonymous
    anonymous:
    Can anyone explain the utility of a HashMap that only holds one thing?
    It is very well possible that it didn't hold one thing. There's a body in that loop that you haven't seen, remember? It could contain, oh, let's say, another loop? Or a function that populates it with another loop? Use your imagination!
  • faoileag (unregistered) in reply to Occam's Strop
    Occam's Strop:
    Why did the original clear the map one million times? The reason is not obvious to me
    So that there is no data from the last iteration in the hash map once the next iteration starts.

    Looks like the developer needed a temporary variable, in this case a hash map, for whatever he had to accomplish during one iteration. With simple types there is no danger with creating them outside the loop; with hash maps things are different since you might iterate over the keys at one point or the other.

    But creating a hash map is rather expensive. So you do it just once (outside the loop) and then just erase whatever's in it once you're done with it inside the loop.

  • (cs)
    Taran is now spending his days wandering.

    How could snoofle have missed this obvious ending line?

  • anonymous (unregistered) in reply to TGV
    TGV:
    anonymous:
    Can anyone explain the utility of a HashMap that only holds one thing?
    It is very well possible that it didn't hold one thing. There's a body in that loop that you haven't seen, remember? It could contain, oh, let's say, another loop? Or a function that populates it with another loop? Use your imagination!
    If it contained (say) another loop, that would be a significant part of the logic and should have been left in. "Snip" is supposed to mean nothing important happened (well, everything important happened, but it's not important to know how it happened). Aside from the clearing and re-using to avoid the hit of allocating and de-allocating, why the hell would you need a million brand-spankin new HashMaps in the first place?
  • (cs) 
      // Original code
  int result = someExpensiveFunc(...);
  if (result > 0) {
     somePermanentVar = result;
  }

  // Refactored code
  // Taran: static calls are free
  // OP: but instantiating objects repeatedly is not
  if (FuncFactory.getInstance()
                 .getHandler(SomeExpensiveFunc.class)
                 .someExpensiveFunc(...)) {

    These are not even remotely doing the same! On Java this obviously wouldn't even compile.

    Type mismatch: cannot convert from int to boolean

    And all the OP complains about is the repeated instantiating of objects?

    Not about breaking the build with a compile error?

    Seems not only Taran is a WTF in this story.

  • anonymous (unregistered) in reply to no laughing matter
    no laughing matter:
      // Original code
  int result = someExpensiveFunc(...);
  if (result > 0) {
     somePermanentVar = result;
  }

    // Refactored code
// Taran: static calls are free
// OP: but instantiating objects repeatedly is not
if (FuncFactory.getInstance()
.getHandler(SomeExpensiveFunc.class)
.someExpensiveFunc(...)) {

    These are not even remotely doing the same! On Java this obviously wouldn't even compile.

    Type mismatch: cannot convert from int to boolean

    And all the OP complains about is the repeated instantiating of objects?

    Not about breaking the build with a compile error?

    Seems not only Taran is a WTF in this story.

    Wait, you mean to say that
    if (1) // do stuff
    won't work in Java?

    Anyway, worse things have happened in the anonymising process. It would certainly be an assumption that I would've made, but the original might have had the "> 0".

    You're right, though, it doesn't do the same thing; the first version would only assign somePermanentVar if the value was a positive number, but the latter will assign it if it's nonzero. Just wait until someExpensiveFunc returns a negative value and everything gets all cocked up because somePermanentVar isn't supposed to ever be negative...

  • (cs) in reply to MoSlo
    MoSlo:
    I rank the 'Obviously' people in the same group as those who keep saying 'clearly'.
    Or literally.
  • (cs) in reply to anonymous
    anonymous:
    If it contained (say) another loop, that would be a significant part of the logic and should have been left in. "Snip" is supposed to mean nothing important happened (well, everything important happened, but it's not important to know how it happened). Aside from the clearing and re-using to avoid the hit of allocating and de-allocating, why the hell would you need a million brand-spankin new HashMaps in the first place?
    Assumption might not be the mother of all fuckups, but it sure is the mother of many. a) Did you notice the 10000000 or whatever in the loop condition? Do you really think that is the true code? That would be quite a WTF. My guess it's that the code has been simplified. A lot. Just to illustrate the performance problem. b) Nobody needs a million new HashMaps, just an empty one. c) Why would nothing happen in a loop? Just because it says "snip"? It has a HashMap, so either someone was iterating over a lot of data, or there is some API call that wants a hash map for a task commonly used in iterations.
  • Teo (unregistered) in reply to Pista

    Good, I'm not the only one who got that joke.

  • anonymous (unregistered) in reply to TGV
    TGV:
    b) Nobody needs a million new HashMaps, just an empty one.
    Yeah, a million times an empty one. So that's my question: What the fuck?
    TGV:
    c) Why would nothing happen in a loop? Just because it says "snip"? It has a HashMap, so either someone was iterating over a lot of data, or there is some API call that wants a hash map for a task commonly used in iterations.
    Again, that's my original question, what could they possibly be doing that needs a fresh clean hash map for each iteration of the loop?

Leave a comment on “Obviously!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article