• Sean (unregistered)

    Success? Flail.

  • captain obvious (unregistered)

    #define DEVELOPER FAILURE

  • (cs)

    #define OUTSOURCING FAILURE

  • Tobias (unregistered)

    #define FAILURE TRUE

  • Vollhorst (unregistered)

    They should at least check against EOF and FileNotFound.

  • (cs)

    #define OUTSOURCEDCODE WORSE_THAN_FAILURE

  • Maks Verver (unregistered) in reply to Tobias
    #define FAILURE TRUE
    I love how this variation-on-a-theme is actually consistent with the definitions in the header file. (This may or may not have been the poster's intention.)
  • (cs)

    Nothing wrong with zero for success and non-zero for failure. That's the traditional Unix way. There's only one way for a function to succeed, and potentially many ways to fail, corresponding to the true/false semantics in C.

    But judging from the rest of this wtf, I'm guessing that's not what motivated this "design".

  • (cs)

    #define FAILURE 1

    I need a t-shirt with that on.

  • German B. (unregistered) in reply to gabba
    gabba:
    There's only one way for a function to succeed, and potentially many ways to fail, corresponding to the true/false semantics in C.

    But in C, 0 is false and non-0 is true. You are implying the opposite, if I got you right (sorry if I didn't)

  • Vollhorst (unregistered)

    Every C/C++-program returns an integer value. 0 == success and everything else is the error code that occurred.

    That's why you can write something like:

    ./configure && make && make install

    The second and third command is only executed if the previous commands returned 0.

  • null (unregistered)

    So for C, zero is false and non-zero is true. Zero is success and non-zero is failure. Those define's aren't really WTF's except for being defined twice.

  • I Just Have To Say It (unregistered)

    Since no one else has said it, I will:

    FILE_NOT_FOUND!

  • Matt D (unregistered)
    Oh, and as for my attempts at showing the boss how bad our outsourced code is? !SUCSESS. After all, the application did work."
    Oy... this really is the worst part of the story. Mostly because I am so intimately familiar with such attitudes. >.<
  • John Doe (unregistered) in reply to I Just Have To Say It
    I Just Have To Say It:
    Since no one else has said it, I will:

    FILE_NOT_FOUND!

    #define BRILLANT "Paula"

  • Southern (unregistered)

    0 is false success 1 is true failure

  • Carl (unregistered) in reply to Vollhorst
    Vollhorst:
    Every C/C++-program returns an integer value. 0 == success and everything else is the error code that occurred.

    That's why you can write something like:

    ./configure && make && make install

    The second and third command is only executed if the previous commands returned 0.

    C/C++ programs don't have to return an int.

  • Anon Fred (unregistered) in reply to Carl
    Carl:
    C/C++ programs don't have to return an int.
    Right, sometimes they can return a Windows object that instantiates a HWND.

    In Unix, though, "return non-zero on failure" is very very common. Windows code seems to have half-absorbed this rul.e

  • Dr. Colossus (unregistered)

    Makes me wonder whether there are books in those outsource-to countries which teach these kinds of 'patterns' - because they seem to be pretty common down there.

  • (cs)

    #define OPER_SUCCESSFUL "SUCS"

  • EasternEgg (unregistered)

    Outsourcing to India sucks!

    Guess who in future gonna clean-up the mess?

  • (cs) in reply to John Doe
    John Doe:
    I Just Have To Say It:
    Since no one else has said it, I will:

    FILE_NOT_FOUND!

    #define BRILLANT "Paula"

    #define PAULA "Brillant!"

    Fixed that for you.

  • Bogglestone (unregistered)

    SUCSESS is a marketing slogan of DonkeyVac, Inc.

    Strange, there was a captcha but it turned into a werewolf and ran away...

  • Fred Annon (unregistered) in reply to Anon Fred
    Fred Anon:
    Carl:
    C/C++ programs don't have to return an int.
    Right, sometimes they can return a Windows object that instantiates a HWND.

    In Unix, though, "return non-zero on failure" is very very common. Windows code seems to have half-absorbed this rul.e

    He didn't say anything about Windows, only C++. As he said, in C++ main can return void, and in such case libc should return 0 to OS (be it Windows, MacOS or Gnu)

  • ddd (unregistered) in reply to Vollhorst
    ./configure && make && make install

    The second and third command is only executed if the previous commands returned 0.

    So 0 && 0 && 0 == SUCSESS? Mind boggles...

  • Henry Miller (unregistered)

    Can sumeboody sent ma thier aderes, eye nede a jab.

    P.S. does tham paid weel?

  • (cs) in reply to Fred Annon
    Fred Annon:
    As he said, in C++ main can return void, and in such case libc should return 0 to OS (be it Windows, MacOS or Gnu)

    The last time I was in a position where I had to care about C or C++ standards, the ISO standards said that main must return int.

    Every compiler in the world let you get away with void, but there was no requirement in the standard that the Deathstation 9000 would behave the same way.

    It's entirely possible that void main() was introduced in the meantime as a C99-ism, making my perspective outdated; but if so I would consider it a shameful caving-in to pressure from the programming book authors that has been (incorrectly) teaching void main() since the 1980's.

  • Borat (unregistered)

    #define GREAT_SUCSESS!

  • Some C++ Guru (unregistered)

    The "bool" type in C++ is not that hot, especially as it comes to STL. To paraphrase (badly) Scott Meyers, from one of the Effective books: There's nothing wrong with an STL collection of bool, so long as you understand it's not really a collection, and it doesn't really have bools in it.

    C++ is a beautiful language; if you have a brilliant mind, it allows you to express things that most other languages can't hope to touch. It's also the idiots' power tool for creating WTFs. My favorite C++ WTF of all time:

    #define private public #define protected public

    That, is pain.

  • whomever (unregistered) in reply to Licky Lindsay
    Licky Lindsay:
    The last time I was in a position where I had to care about C or C++ standards, the ISO standards said that main must return int.

    The standard still does. Even the latest C++0x draft, section 3.6.1.2:

    ... It shall have a return type of int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: 
    int main() { /* ... */ }

    and

    int main(int argc, char *argv[]) { /* ... */ }

    ...

  • Anon Fred (unregistered) in reply to Fred Annon
    Fred Annon:
    As he said, in C++ main can return void, and in such case libc should return 0 to OS (be it Windows, MacOS or Gnu)
    Maybe in Visual C++.NET 98, but not in legit C++.

    Main must return int in C++.

  • Paul (unregistered)

    I used to work for an outsourcing company before getting a real job, and this doesn't surprise me.

    We didn't have source control or code reviews, the developers wrote the QA tests and carried them out, and we didn't have a bug tracking system (although one team leader introduced a system using sheets of paper, one for each bug, and folders named "OPEN", "ASSIGNED", "RESOLVED" etc).

    Some code we developed for a major British Telecom company (which is now known by its initials) was a mail access layer. It worked fine for our developers and during QA. But the week before delivery one or our developers decided to take a look at what would happen if two or more users accessed their email simultaneously. There was, I believe, a null pointer dereference and the code crashed.

    An emergency late night debugging session eventually revealed that account details were stored in a single global variable.

    A couple of years later, when in general we actually knew a bit more about what we were doing, a project another team worked on was benchmarked an order of magnitude faster than any other similar application we tested ... with one user. Each additional sign on reduced performance by a half, ie. with five users performance was 1/16.

  • (cs)

    Looks to me like the mis-spelling "SUCSESS" might actually be deliberate, so that when you call Admin:Update() you can distinguish between OPER_SUCCESSFUL and actual success!

  • (cs) in reply to Paul
    Paul:
    An emergency late night debugging session eventually revealed that account details were stored in a single global variable.

    I'm fairly certain that my former employer once hired the same guy who wrote that... "User ID in a static variable on a web application? What's wrong with that?"

  • (cs) in reply to Paul
    Paul:
    We didn't have source control or code reviews, the developers wrote the QA tests and carried them out...
    Developers should NEVER be the sole testers of their own code. I learned this lesson well while writing an application for the Production Control department of a fabrication company. I would work for two weeks on the code, and then test for a couple of days in every way that I could conceive. When I thought it was bulletproof, I would deliver it to the Production Control manager, who was generally able to bring it to its knees within about eight seconds.

    And in disbelief at the idiotic thing he had just done, I would say, "Why in god's name would you do something like that?"

    And he would reply, "Because my employees will do it."

    Yep, you don't want to be the tester of your own code. You're too intimate with it; you know what to do with it. It must be released to the idiots if it is to be idiot-proof.

  • Dana (unregistered)

    const int TRUE = 1; const int FALSE = 0;

    Works in any C99 compatible compiler and does away with annoying macro precedence problems, redefinitions, debugging problems, etc, etc.

    captcha: genitus

  • (cs) in reply to Dana
    Dana:
    captcha: genitus
    Ah yes, famous Roman warrior. Son of Copulus and Labia.
  • 008 (unregistered)

    #define FILE_NOT_FOUND 404

  • Bob N Freely (unregistered) in reply to EasternEgg
    EasternEgg:
    Outsourcing to India sucks!

    Guess who in future gonna clean-up the mess?

    Contractors in China?

  • (cs) in reply to German B.
    German B.:
    gabba:
    There's only one way for a function to succeed, and potentially many ways to fail, corresponding to the true/false semantics in C.

    But in C, 0 is false and non-0 is true. You are implying the opposite, if I got you right (sorry if I didn't)

    No. The point here, the point that gabba was making, is that C's true/false semantics are analogous to success/failure semantics, if truth is treated as equivalent to failure and falsehood is treated as equivalent to success.

    As gabba said, there's only one way to succeed, but many ways to fail. And as you said, there's only one way to be false, but many ways to be true. Therefore, it makes sense for the single false value (zero) to map to the single success value, and for the many true values (anything with at least one bit set to 1) to map to the many failure values.

  • dkf (unregistered) in reply to FredSaw
    FredSaw:
    Developers should NEVER be the sole testers of their own code.
    Well... an automated test suite is a good thing in any case, and should probably be in two parts. Firstly, a chunk of specification-driven tests (which can be written before the code) and secondly, a load of tests that should try to exercise every branch (but not every path!) in the code (use a coverage tool to help). This all represents tests that the developer can write, should write, and should be in the habit of running regularly. Not that this is enough, but it at least lets you get a bunch of tests that you can run as part of your own incremental build workflow, and so get an immediate check for stupidity.

    Then the code goes to QA, who should write their own tests and check across a wide range of platforms (assuming you're not going to deploy on a single target).

  • (cs)

    sucks cess.

  • C (unregistered)

    The bad thing about defining FAILURE and TRUE to be the same value is that it lets you return TRUE or FALSE when you should be returning FAILURE or SUCCESS. If you're going to go through the hassle of defining your own custom return codes, why not create custom types, so that the compiler can check types for you, and make sure you're not about to shoot yourself in the foot.

  • David (unregistered) in reply to Vollhorst
    Vollhorst:
    Every C/C++-program returns an integer value. 0 == success and everything else is the error code that occurred.

    Actually, the standard says that it returns EXIT_SUCCESS on success and EXIT_FAILURE on failure. What those values are is left up to the implementation. It is worth noting that they don't have to be zero and one. On Solaris and Unix the ones and zeros are switched, and I can never remember which one is which (hence why you are supposed to use the constants in stdlib.h )

    I learned this from a C professor who insisted that anything we write for his class be portable onto both systems.

  • (cs) in reply to dkf
    dkf:
    FredSaw:
    Developers should NEVER be the sole testers of their own code.
    Well... an automated test suite is a good thing in any case, and should probably be in two parts. Firstly, a chunk of specification-driven tests (which can be written before the code) and secondly, a load of tests that should try to exercise every branch (but not every path!) in the code (use a coverage tool to help). This all represents tests that the developer can write, should write, and should be in the habit of running regularly. Not that this is enough, but it at least lets you get a bunch of tests that you can run as part of your own incremental build workflow, and so get an immediate check for stupidity.

    Then the code goes to QA, who should write their own tests and check across a wide range of platforms (assuming you're not going to deploy on a single target).

    All true. Before arriving at this point, a developer will need the resources (time, training, whatever) to learn how to write tests and a department will need the funding to establish a QA section.

  • Jon (unregistered) in reply to captain obvious
    captain obvious:
    #define DEVELOPER FAILURE
    #define DEVELOPER 2
  • jbinaz (unregistered) in reply to Anon Fred
    Anon Fred:
    In Unix, though, "return non-zero on failure" is very very common. Windows code seems to have half-absorbed this rul.e

    Yeah, SQL Server returns non-zero for its actual error codes. A zero is "woo-hoo! Your statement rocks!"

  • (cs)

    Nothing sucks seeds like sucsess.

  • Roy-G-BIV (unregistered)

    Maybi hiz boss wantid to ahdopt a nu, mor lojicul speling ov wurds like sucsess?

    Ouch! That was painful to type.

  • (cs) in reply to David
    David:
    Vollhorst:
    Every C/C++-program returns an integer value. 0 == success and everything else is the error code that occurred.

    Actually, the standard says that it returns EXIT_SUCCESS on success and EXIT_FAILURE on failure. What those values are is left up to the implementation. It is worth noting that they don't have to be zero and one. On Solaris and Unix the ones and zeros are switched, and I can never remember which one is which (hence why you are supposed to use the constants in stdlib.h )

    I learned this from a C professor who insisted that anything we write for his class be portable onto both systems.

    You're making that up.

    For one thing, a return of 0 does have to be equivalent to a return of EXIT_SUCCESS, though EXIT_SUCCESS does not actually have to be defined as 0. For another thing, solaris is a unix variant, and in all unix variants (on unix systems, the C standard is not the only standard in play) and also on MS windows, EXIT_FAILURE is 1 and you are also allowed to return any value from 0 to 255 (greater values than 255 may be cut off to the last eight bits)

Leave a comment on “SUCSESS?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article