• tbrown (unregistered) in reply to RIF
    RIF:
    DeLos:
    Johnny Anklebiter:
    It's bad code. But why wasn't it working?

    I am assuming because the code was unable to handle the additional fields on the new form.

    Assumption is the mother of all f*ckups.

    Needs more generic.

    That would be "Needs more animal worn noise device!"

  • peterb (unregistered) in reply to Just Some Guy
    Just Some Guy:
    Nope. I'm just too lazy to to back and change everything later just because I believed the boss when he swore that we would never need a certain feature. In my experience, that turns out to be incorrect about 95% of the time.

    I wonder if that's a variation of Clarke's first law. (http://en.wikipedia.org/wiki/Clarke's_three_laws)

    "If a manager says we will never need a certain features, he's possibly wrong. If a manager says we well need this supposedly feature later, he's possibly wrong."

  • SomeCoder (unregistered) in reply to Gabelstaplerfahrer
    Gabelstaplerfahrer:

    That form makes my eyes bleed.

  • Garrett Fitzgerald (unregistered) in reply to Someone You Know
    Someone You Know:
    Jake Vinson:
    Working on an application that will only ever be used by the local government in Podunk, MA?

    Podunk is in Michigan. Podunk, MA is actually called "Florida".

    And then, just to mess with mailshops everywhere, there's Ontario, CA.

  • Zap Brannigan (unregistered) in reply to SomeCoder
    SomeCoder:
    Gabelstaplerfahrer:
    That form makes my eyes bleed.
    Excellent background color. You must hate your customers.
  • (cs) in reply to Matt
    Matt:
    brazzy:
    Definitely. There is no program that can't be improved upon by making it more generic (usually involves tripling the code size and quintupling the time required to make any changes that were not foreseen by the genericiser).

    Isn't the point of making code generic that you don't have to make changes to it in order to do something else??

    :D

    In theory, yes. In practice, you usually end up making a certain narrow class of changes easier, at the cost of making all other changes harder (MUCH harder if you do it badly). In the worst case, you try making any change possible through some configuration file, and thereby create a configuration file format that's basically a very badly designed Turing-complete programming language with an inefficient, buggy interpreter remaining as the shell of your application code.

  • (cs) in reply to brazzy

    EXACTLY! I tend to say: if you try to build the most perfect, most versatile and universal piece of software, you'll end up with a program that run-time compiles the configuration file. The configuration file will end up as a piece of source code, and will be just as difficult to maintain.

    So: the most perfect piece of software ever written is the IDE.

  • (cs) in reply to brazzy
    brazzy:
    Matt:
    brazzy:
    Definitely. There is no program that can't be improved upon by making it more generic (usually involves tripling the code size and quintupling the time required to make any changes that were not foreseen by the genericiser).

    Isn't the point of making code generic that you don't have to make changes to it in order to do something else??

    :D

    In theory, yes. In practice, you usually end up making a certain narrow class of changes easier, at the cost of making all other changes harder (MUCH harder if you do it badly). In the worst case, you try making any change possible through some configuration file, and thereby create a configuration file format that's basically a very badly designed Turing-complete programming language with an inefficient, buggy interpreter remaining as the shell of your application code.
    Some configuration file? As in "a single?" You're either lucky, or you're working on a relatively recent application.

    Last one I worked on had a configuration file for the "product," a configuration file for the "market," a configuration file for the "client," a database table for the jobs to be run, a database table mapping the sub-tasks to the job ... all of which were in different formats, with different naming conventions and different parsers, and all of which had order-dependent side-effects on all of the others. Plus hard-coded defaults scattered around the code. Oh, and three different error logs in the database, plus two each in flat-file format for each job. That's what ten years of cruft does for ya. Probably Turing-complete, but it'd be a PhD project to prove it.

    On a slightly different note, I think the discussion of generalisation is over-influenced, as so often these days, by the prevalence of Web applications. Ignoring laudable efforts with i18n and locales, gemeralising these tends by their nature to be simple code-twiddling, as with the wretched effort in the OP.

    It's a myth that generalisation is intended to "avoid" making future changes to the code when functionality changes. Generalisation has little or nothing to do with code -- that would be refactoring. Generalisation, I suggest, is more appropriate at the design level (and few Web pages are "designed"); and the intention is to make everything as orthogonal and encapsulated as possible, thus allowing future changes to slide in without side-effects. Unlike with the abortion I mentioned above.

  • MeRp (unregistered) in reply to Zap Brannigan
    Zap Brannigan:
    SomeCoder:
    Gabelstaplerfahrer:
    That form makes my eyes bleed.
    Excellent background color. You must hate your customers.

    If you think that is bad, go to the main site.

    I wish I'd worn the goggles; even though I've heard they do nothing, at very least they would have caught my melted eyeballs and prevented them from staining my shirt.

  • d.k. Allen (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Mobile guru:
    Martin:
    He also correctly used "Constant".equals(Variable) instead of the usual novice error of Variable.equals("Constant") to prevent null pointers.
    WTF?! This doesn't prevent null pointers, instead it HIDES real error. This is the same thing as enclosing all code in try/catch and ignoring exception, thinking you "prevented" them!

    Null pointers prevented by proper design and right tools.

    Uhhh what? Most of the time doing something like that just prevents you from checking if the pointer is null in the first place. Example:

    public boolean isAwesome(String s)
{
  if(s == null)
    return false;

  return s.equals("Awesome");
}

    Becomes:

    public boolean isAwesome(String s)
{
  return "Awesome".equals(s);
}

    Most of the time you're not "hiding" anything.

    Both of these are broken. The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check. If the code can get this far with s being null, then the design is broken, or there is a bug. Either of the quoted solutions, does indeed hide this failure.

  • Master Kung fu (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Uhhh what? Most of the time doing something like that just prevents you from checking if the pointer is null in the first place. Example:
    public boolean isAwesome(String s) { if(s == null) return false;

    return s.equals("Awesome"); }

    Becomes:

    public boolean isAwesome(String s) { return "Awesome".equals(s); }

    What a mess. NULL can't be un-awesome. Here is correct code, in case you don't get it

    public boolean isAwesome(String s)
{
  if(s == null)
    throw new IllegalArgumentException("Not a valid quality: "+s);
  return s.equals("Awesome");
}

    Event getting NullPointerException and tracking point where data was unexpected null (became invalid) is BETTER than masking this error, turning EXCEPTION into NORMAL behavior!

  • Zap Brannigan (unregistered) in reply to MeRp
    MeRp:
    Zap Brannigan:
    SomeCoder:
    Gabelstaplerfahrer:
    That form makes my eyes bleed.
    Excellent background color. You must hate your customers.

    If you think that is bad, go to the main site.

    I wish I'd worn the goggles; even though I've heard they do nothing, at very least they would have caught my melted eyeballs and prevented them from staining my shirt.

    HOLY F**K! I went to the homepage. Please everyone stay away! It's worse than goatse!

  • dontmatter (unregistered) in reply to JD
    JD:
    Personally, I always aim to make components as generic as possible. The platform I'm working on at the moment is so generic that I can customise both the look and the behaviour of it with just a few lines of human-readable text. I call it a "programming language" and I can do just about anything I want with it.

    Did you invent a language for GUI programming? Wow!

  • RiF (unregistered) in reply to tbrown
    tbrown:
    RIF:
    DeLos:
    Johnny Anklebiter:
    It's bad code. But why wasn't it working?

    I am assuming because the code was unable to handle the additional fields on the new form.

    Assumption is the mother of all f*ckups.

    Needs more generic.

    That would be "Needs more animal worn noise device!"

    This?

    http://cru.cahe.wsu.edu/CEPublications/eb1677/eb1677.html

  • (cs) in reply to Zap Brannigan

    Absolutely horrifying! For extra bonus points, check the company that hosts it.

    I rebuilt this website from a flat HTML website, in the old days of ASP.NET 1.0 - it was a horrible job. I even designed a Windows GUI to change the contents and banners, and guess what: we never used it.

  • /Arthur (unregistered)

    I think its a program for a undertaker.

  • Tina Turner (unregistered)

    Wow, squared is cool! I like squared!

    Jiff www.privacy.es.tc

  • K (unregistered) in reply to Franz_Kafka
    Franz_Kafka:
    K:
    Then I explained the project lead why there still was one of those bugs left and that we had to remove the last buggy copy and replace it with a call of the method that did things right. His response was, that we were too close to the deadline for such changes, so we just had to fix the bug in the remaining instance of the code instead.

    That makes sense from a risk mitigation standpoint - don't change large chunks of code right before release. Did he schedule a bugfix to do the proper thing after release?

    It was hardly a large chunk of code. It was simply a matter of replacing a 20 line piece of buggy code with a call of a thoroughly tested method doing the same thing except from the bugs.

    And no, nobody scheduled a proper fix after the release, because there was at least five new features that had to be released every week. They weren't huge new features, but they did take time to get working because of more fundamental flaws, which there clearly wasn't time to work on fixing.

    I have left the project. I would guess the project is still in the same shape as it was.

  • TomatoQueen (unregistered) in reply to Gabelstaplerfahrer
    Gabelstaplerfahrer:
    Absolutely horrifying! For extra bonus points, check the company that hosts it.

    I rebuilt this website from a flat HTML website, in the old days of ASP.NET 1.0 - it was a horrible job. I even designed a Windows GUI to change the contents and banners, and guess what: we never used it.

    There's nothing wrong with the registration form itself, it's the text above it that was translated by Babelfish from the original AllYourBase.

    The home page is Abomination and Must Be Destroyed.

  • function replyToComment(string quote) (unregistered) in reply to Messy Wiper
    Messy Wiper:
    function replyToComment(string quote) { string action = String.Empty; 
    if(quote.Retarded == true)
{
     action = "Go home and take your fail with you";
} 
else
{
     action = "Go $@$% yourself";
}

return action;

    }

    thank goodness when you pass this comment in, it doesn't fall through

    Go home and take your fail with you

  • (cs) in reply to d.k. Allen
    d.k. Allen:
    Both of these are broken. The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check. If the code can get this far with s being null, then the design is broken, or there is a bug. Either of the quoted solutions, does indeed hide this failure.

    The point is defense in depth - you don't want one error to blow up your whole codebase. Instead, it should act sensibly and reject null values.

  • Podunkite (unregistered) in reply to Walleye

    Actually, there is a Podunk, MA, as well... but it is an unincorporated village within the town of East Brookfield.

    And it's small enough not to show up on MapQuest.

  • (cs) in reply to brazzy

    Oh man this is just so wrong on so many levels. If brazzy is another TopCod3r, I'm suckered in completely.

    brazzy:
    [Generic coding] seems perfectly reasonable until you've gone "generic" a few times and realized that the extra work you put into it was wasted because it was an isolated special case after all,
    It's not wasted until you go out of business.
    brazzy:
    or got burned by changing requirements that you "generic" solution didn't cover, but DID make far more difficult to implement than with a simple, straightforward solution.
    ...in which case it wasn't generic, but simply gave the appearance of being generic -- much like TFA.
    brazzy:
    Yeah, requirements will change. But often not they way you expect them to.
    In which case you're not up to writing generic code.
    brazzy:
    And the overall most flexible solution that can accomodate ANY change in a short time is usually a simple, straightforward one that does not involve config files or code generation.
    You mean change the expectations to fit the program? Wow.
  • (cs) in reply to rfsmit

    My name has been coming up a lot in the comments of this story. I haven't posted yet today because I have been busy trying to figure out if I have any money left after congress flushed it all down the toilet. I might have to pass a few more certification exams to get some additional bonuses.

    Anyways, I don't really think the code for this is a WTF like many of you do. Once again it is taken out of context. If you are a front-end developer, you will probably not understand the reason why it is done like this, but think about whether you want to have code spread out into a bunch of event handlers, or whether you want it consolidated into a central location for maintenance purposes. The person who inherits the code later will thank you (I have personally received thanks before from people who have inherited my code).

    The real WTF is why java makes you use equals(). That is just another example of how VB is better and VB programmers are more efficient...

    If userField.Name = "From" Then Else if userField[i].Name = "SendTo" Then Else ...

    or better yet, VB lets you do a Select/Case. I will leave that as an exercise up to you. Hint: If you learn how to use select/case it will greatly improve your coding style, but don't fall in love with it because it can have a severe performance penalty. But for junior developers, I suggest not worrying about performance right now, so don't worry about that yet.

    [i]Addendum (2008-09-29 18:52): Edit: Thanks SomeCoder, for pointing out that I should have used () instead of []. I was trying to hammer out this comment, so I was lazy, but I certainly wouldn't want to mislead a new developer into thinking you could index into an array with [] in VB.

  • right side of the pond (unregistered) in reply to Walleye

    Isn't the generic Podunk in Illinois?

  • (cs) in reply to pink_fairy
    pink_fairy:
    It's a myth that generalisation is intended to "avoid" making future changes to the code when functionality changes.
    Actually, misunderstood and badly done generalization is exactly that. It strives to make behaviour "configurable", as if, by extracting behaviour into a configuration file, it magically is easier to change than source code, cannot contain errors and does not need to be tested. I suspect this tendency arises when one has had bad experiences with large C++ projects that take forever and a day to compile and have a godawful build process that requires lots of manual steps and may fail late in a way that forces you to start over.
    Generalisation has little or nothing to do with code -- that would be refactoring. Generalisation, I suggest, is more appropriate at the design level (and few Web pages are "designed"); and the intention is to make everything as orthogonal and encapsulated as possible, thus allowing future changes to slide in without side-effects. Unlike with the abortion I mentioned above.
    I'd simply call this "good design".
  • SomeCoder (unregistered) in reply to TopCod3r
    TopCod3r:
    If userField[i].Name = "From" Then Else if userField[i].Name = "SendTo" Then Else ...

    I haven't done VB(.NET) in a long ass time (for good reasons I might add) but aren't arrays indexed with the () operator rather than []?

    feeds the trolls

    :)

  • wtf_is_the_comments (unregistered)

    in after everyone who's never heard of "premature optimization", YAGNI, or Agile.

  • (cs) in reply to rfsmit
    rfsmit:
    It's not wasted until you go out of business.
    It most certainly is wasted if it never gets used.
    rfsmit:
    brazzy:
    or got burned by changing requirements that you "generic" solution didn't cover, but DID make far more difficult to implement than with a simple, straightforward solution.
    ...in which case it wasn't generic, but simply gave the appearance of being generic -- much like TFA.
    I'd estimate that upwards of 80% of the code that explicitly claims to be "generic" or "general" and was written with that intention falls into that category.
    rfsmit:
    brazzy:
    Yeah, requirements will change. But often not they way you expect them to.
    In which case you're not up to writing generic code.
    IF you believe this has anything to do with the developer's skills, you're not up to writing code, period.
    rfsmit:
    brazzy:
    And the overall most flexible solution that can accomodate ANY change in a short time is usually a simple, straightforward one that does not involve config files or code generation.
    You mean change the expectations to fit the program? Wow.
    You don't seem to understand what I wrote. Try reading it again. What I meant is to program what is required now, not what you think might be required in the future (not even what the bird entrails tell you), and keep it as simple as possible, so that the *actual* future requirements will be easy and quick to implement.
  • (cs) in reply to SomeCoder
    SomeCoder:
    TopCod3r:
    If userField[i].Name = "From" Then Else if userField[i].Name = "SendTo" Then Else ...

    I haven't done VB(.NET) in a long ass time (for good reasons I might add) but aren't arrays indexed with the () operator rather than []?

    feeds the trolls

    :)

    Thanks for catching that. I guess when you have been coding VB as long as I have you begin to overlook the minute details. One of the good things about VB is that the IDE takes care of all this for me, but since I was trying to make a point in the comment window, I did not check the syntax.

  • JimBob (unregistered) in reply to Mobile guru
    WTF?! This doesn't prevent null pointers, instead it HIDES real error. This is the same thing as enclosing all code in try/catch and ignoring exception, thinking you "prevented" them!

    Null pointers prevented by proper design and right tools.

    Unless it's valid for usedField[x] to be null. Every time I see someone make a stupid blanket statement like this, I thank FSM that they are not on my project team.

  • JimBob (unregistered) in reply to K
    K:
    Then I explained the project lead why there still was one of those bugs left and that we had to remove the last buggy copy and replace it with a call of the method that did things right. His response was, that we were too close to the deadline for such changes, so we just had to fix the bug in the remaining instance of the code instead.
    Ugh. Unless it will take /more/ time to implement a solution like that thus impacting the project schedule - easier to ask forgiveness than permission
  • (cs) in reply to JimBob
    JimBob:
    WTF?! This doesn't prevent null pointers, instead it HIDES real error. This is the same thing as enclosing all code in try/catch and ignoring exception, thinking you "prevented" them!

    Null pointers prevented by proper design and right tools.

    Unless it's valid for usedField[x] to be null. Every time I see someone make a stupid blanket statement like this, I thank FSM that they are not on my project team.

    You're right. I agree 100%.

    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

  • (cs) in reply to TopCod3r
    TopCod3r:
    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    Is this one of those trolls, or do you actually do this?

  • Scottford (unregistered) in reply to TopCod3r
    TopCod3r:

    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    TDWTF is so much more entertaining these days. Thanks, TopCod3r.

  • Just Some Guy (unregistered) in reply to TopCod3r
    TopCod3r:
    You're right. I agree 100%.

    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    You, good sir, are a genius.

  • I walked the dinosaur (unregistered)

    Sweet Home Null - Where Nulls Just Want To Have Fun!

  • (cs) in reply to d.k. Allen
    d.k. Allen:
    The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check. If the code can get this far with s being null, then the design is broken, or there is a bug. Either of the quoted solutions, does indeed hide this failure.
    Would that be a good place for an assertion?
  • TK (unregistered) in reply to Gabelstaplerfahrer
    Gabelstaplerfahrer:
    EXACTLY! I tend to say: if you try to build the most perfect, most versatile and universal piece of software, you'll end up with a program that run-time compiles the configuration file. The configuration file will end up as a piece of source code, and will be just as difficult to maintain.
    You just described emacs.
  • Dave (unregistered) in reply to Franz_Kafka

    assert(isAwesome(NULL) == NULL) ' Ternary Logic is valuable in this component

  • http://109.livejournal.com (unregistered) in reply to TopCod3r
    TopCod3r:
    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    wow! this is the best wtf of the month, if not of the year.

    there are two widely accepted ways to do it.

    one is more theoretical and demands that you use null to indicate that the value is unknown. when null is used to indicate unknown, it becomes more obvious that you can't know if it's less or greater than some other value or if one unknown is equal to another unknown. that's why you have this weird null arithmetic.

    design resulting from this approach allows all non-required properties to be nullable. code is usually pretty complicated because null values need special handling.

    another approach is more practical. it says that if you have reasonable default value for the property and there is no explicit requirement to store "unknown" status, make your property not nullable and use your default instead of null.

    in this design, most or all properties are non-nullable; code is usually simpler and has less bugs (but the memory of the property actually being unknown is lost).

  • RiF (unregistered) in reply to TopCod3r
    TopCod3r:
    That is just another example of how VB is better and VB programmers are more efficient...
    shhhhhh...too obvious....
  • (cs) in reply to http://109.livejournal.com
    http://109.livejournal.com:
    TopCod3r:
    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    there are two widely accepted ways to do it.

    one is more theoretical and demands that you use null to indicate that the value is unknown. when null is used to indicate unknown, it becomes more obvious that you can't know if it's less or greater than some other value or if one unknown is equal to another unknown. that's why you have this weird null arithmetic.

    design resulting from this approach allows all non-required properties to be nullable. code is usually pretty complicated because null values need special handling.

    another approach is more practical. it says that if you have reasonable default value for the property and there is no explicit requirement to store "unknown" status, make your property not nullable and use your default instead of null.

    in this design, most or all properties are non-nullable; code is usually simpler and has less bugs (but the memory of the property actually being unknown is lost).

    Never underestimate the beauty of SQL code with "WHERE $column IS NOT NULL" in this type of design

  • (cs) in reply to TopCod3r
    TopCod3r:
    You're right. I agree 100%.

    Often times I use null to indicate that the user chose the default value. So for example, for gender the default value is male, so I use null in the database to indicate male, and 1 for female. Same for states... the null value is Alabama, since it is first alphabetically and shows up first in the drop down list. So again, null indicates Alabama, 1 = Alaska, 2 = Arizona, etc. in both cases I use 0 (zero) to indicate that the question was left blank.

    Ooooh, I like it! Definitely a strategy born of MS Accesses best feature: joining on null values. Don't know where I'd be without, personally...

  • (cs) in reply to JimBob
    JimBob:
    Null pointers prevented by proper design and right tools.
    Unless it's valid for usedField[x] to be null. Every time I see someone make a stupid blanket statement like this, I thank FSM that they are not on my project team.
    Of course, the real problem is that our beautifully crafted projects are given to users, who inevitably mess them up; and our beauftifully crafted code libraries are used by other developers, who inevitably mess them up.

    There's no telling when someone will take it into their head to find a way to provide a null reference to a method, so deal with it appropriately. If being passed a null reference means the method can't perform any meaningful function then throw; but if the method can reasonably interpret the null reference and perform its function regardless then it should (just make sure you document the result when null is passed!).

    I occassionally make the ability to pass null a feature: for instance, I have a method that returns a data table from a particular database given the name of the stored procedure and a collection of parameters. If the sp doesn't need paramaters, then what are my options? Reimplement the same method but without the parameter adding code? Make consumers of the code create and pass an empty collection object? Or let them pass null and deal with it appropriately?

  • ChrisB (unregistered)

    Of course, TRWTF is that it takes the To address directly from the form, so what you have here is a generic spam gateway.

  • (cs) in reply to d.k. Allen
    d.k. Allen:
    Both of these are broken. The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check. If the code can get this far with s being null, then the design is broken, or there is a bug. Either of the quoted solutions, does indeed hide this failure.

    Amazing! Without knowing the specs for this particular codebase, you can just automatically detect that it's broken! I'm impressed with your abilities.

    Not. It's possible that a null value OR "Awesome" are both allowable, but other values are not, for one thing. For another, any moron who can try and pronounce something as wrong without knowing anything about it is just that - a moron.

    Try again soon. You'll actually find something correct to say someday....maybe.

  • (cs) in reply to KenW
    KenW:
    d.k. Allen:
    The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check.
    Amazing! Without knowing the specs for this particular codebase, you can just automatically detect that it's broken! I'm impressed with your abilities.
    You're missing the rtue wonder of d.k.'s comment - somehow the program calling isAwesome() is meant to know that s cannot be null without ever checking it. Prescient codebases? Or Schroedinger's variable? Now that's progress... ;^)
  • jDeepBeep (unregistered) in reply to akatherder
    akatherder:
    public function Canadify($phrase){
   $phrase.=", eh?";
   return $phrase;
}

    Too specific, please genericize.

  • (cs) in reply to SomeCoder
    SomeCoder:
    Gabelstaplerfahrer:

    That form makes my eyes bleed.

    When your six month old son throws up the mashed peas you fed him for dinner... please, for the love of $deity, do not make it your background color on your webpage.

Leave a comment on “The Magic Wand of Generic”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article