• Crazy Dutch Bastard (unregistered)

    I must be insane.

    Captcha: secundum - comes after fristum

  • Vamp (unregistered)

    I have done that with constants before. For example timeouts or similar:

    const int TWO_MINUTE_CONSTANT = 2 * 60;

    Makes it easier to read for me later. Maybe it was something similar for those 2 values :)

  • Turd Blossom (unregistered)

    const maxVolume = 10 + 1;

  • Christian (unregistered)

    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.

  • portablejim (cs)

    At least you have the magic values in one place instead of spread out inside the class.

  • Other Nagesh (unregistered) in reply to Christian
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.

    Or you could use multiple random number generators and randomly select the one to use for enhanced super-randomness.

  • AGray (unregistered)

    Constants in a class may or may not be a WTF - I'd honestly rather deal with a constant defined at the class level (preferably, in a Constants region) where I can easily find, identify, and maintain it, than have to sift through a bunch of code to find a method-level constant.

    The value of that constant though...I think that's TRWTF.

    Captcha: enim - must be Eminem's little brother.

  • Severity One (cs) in reply to Christian
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.
    Would you mind giving an example where a non-random random number makes sense?
  • CT (unregistered)

    probably some serious backstory to that 199 + 6. I have some humorous (to me anyway) code like that for managers who are decidedly NOT developers and have weird ideas about what is right.

  • Testing Troll (unregistered) in reply to Christian

    Or... you could do the sane thing and seed the PRNG with a constant when you're unit testing, and let it be seeded with the system time for normal operations...

    CAPTCHA: conventio... if you follow the conventio you won't produce WTF-ridden code.

  • Andrew (unregistered)
    "I don't even want to know why a constant is declared inside a class...
    Because that's the way it's done in Java? Yes, I know that this is probably .NET/C#, but the guy might not be thinking that way.

    Captcha: veniam. That's the way we coded in Ve'niam.

  • zelmak (cs) in reply to Severity One
    Severity One:
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.
    Would you mind giving an example where a non-random random number makes sense?
    Similar to this method for having a fake clock.
  • Tony (unregistered) in reply to Severity One

    Here's a couple:

    1. Using random numbers for a short wait time so a server doesn't get hit with a lot of requests (ala ethernet collsion algorithm) - You might want to have a non random number to see how the server behaves when it does get hit simultaneously

    2. Boundary checking - you might expect random numbers to be in a certain range, but for testing purposes, you could simulate numbers at the boundary or across the boundary

  • Fool (unregistered)

    I do things like 199+6 isntead of 205 on occasion.

    2 reasons:

    1. I am often doing math where I might look at the code one day and say, why the heck did I put 205 there? But looking around I see the numbers 195 and 6 somewhere else in the code.

    2. 199+6 compiles to 205 so it should be equivilent to 205 in the binary file that is generated.

  • Mike (unregistered) in reply to Other Nagesh
    Other Nagesh:
    Or you could use multiple random number generators and randomly select the one to use for enhanced super-randomness.

    But which random number generator would you use to select which random number generator to use for your super random number generator?

  • DonaldK (unregistered)
    CT:
    probably some serious backstory to that 199 + 6

    If you walk the version control commit history might get something like:

    [Source change 382] const int expected_length = 199; [Comment block] Should be fine for all cases

    [Source change 383] const int expected_length = 199 + 1; [Comment block] I'm sure it was some zero based issue

    [Source change 384] const int expected_length = 199 + 2; [Comment block] Wierd. +1 should have worked

    [Source change 385] const int expected_length = 199 + 3; [Comment block] Makes sense now... it's 2 UNICODE char's -1 (since it's zero based)

    [Source change 386] const int expected_length = 199 + 4; [Comment block] Still didn't work... +4 should be OK I'm sure

    [Source change 387] const int expected_length = 199 + 5; [Comment block] Still crashing! We really need to look at this logic

    [Source change 388] const int expected_length = 199 + 6; [Comment block] Praying this will be enough for all cases

  • Nagesh (unregistered)

    In java, ain't declared quite the seme. Writen like this:

    public static final int EXPECTED_LENGTH = 199 + 5;
    

    Constant declared in class for purpose of scope. Concretion values being used for purpose of showing how result is being found. Unfortunate after meking us wating a day, Alex provide code semples that is not being WTF. :(

  • Tyler (unregistered)

    Looks like a normal thing to do. He has a fixed length string of 199 characters that has 6 chars appended to the end.

    As for "within a class" sounds good, better than global, I've even done such things as:

    //Tightly-Scope { int bPtr=0,ePtr=0; ... } (No if statement/while block etc. to set off the block).

  • Nick (unregistered)

    199 - clearly they are zero based arrays, and the max line length is 200 chars.

    Now if that line is sent elsewhere, then it is going to be bundled into a buffer. You will need an overhead for the message type, and the length of the text being sent. I would suggest that is 2 bytes for the message, and 4 bytes for the length. Or 4 and 2.

    Hence the 6.

    Would be better if that was a constant in its own right.

    e.g

    max_line = 199 protocol_size = 6 message_size = max_line + protocolsize

  • C-Octothorpe (cs)
    // We need to give 110% here...
    const double MAX_EFFORT = 1D + 0.1D;
  • Gazzonyx (cs)

    TRWTF is that there isn't a comment on the magic numbers there. Not that there is anything wrong with something like this, but it should be documented. For instance, this is one of my commits to Samba :

    [...]

    • /* domain/username%password */
    • const int max = MAX_DOMAIN_SIZE +
    •             MAX_USERNAME_SIZE +
      
    •             MOUNT_PASSWD_SIZE + 2;
      

    [...]

  • snoofle (cs) in reply to Severity One
    Severity One:
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.
    Would you mind giving an example where a non-random random number makes sense?
    If you want to write a test where you need predictable results, then you'll need to know the "random" inputs in advance.
  • Nagesh (unregistered) in reply to Tyler
    Tyler:
    As for "within a class" sounds good, better than global
    Agreed. TOS ain't understanding scope is TRWTF.
  • Matthew (unregistered) in reply to Severity One

    Repeatability testing.

    If I'm testing a simulation program, I may want to run the simulation under the same set of constraints repeatedly for testing, but use random numbers in production.

  • ZPedro (cs)

    You don't get it. This is like an encounter in a Cthulhu mythos RPG, where you have to roll a dice to know if you are staying sane. Same here, the original coder put an unfathomable expression to force any future reader of the code into insanity if he wasn't sane enough already, thus avoiding borderline cases from going any further - and he helpfully documented he was doing this. Think of it as an assert on the maintenance programmer, forcing him to exit with insanity if he fails the check.

  • concerned citizen (unregistered)

    Yeah, I gotta say, I don't see a WTF here except for maybe not having a comment explaining where the 199 and 6 came from. And like hell if I'm going to throw stones in that glass house!! :p

  • Lockwood (unregistered)

    [Insert xkcd random number thing here.]

    199+6? Simple explanation time? Expected length used to be 199. There was some reason deep in the logic or spec that said "We need it to be 6 longer". They did 199 + 6 rather than 205, expecting it to be respecced and it being easier that way.

    (I've got code that is now sadly barely maintainable because the spec and calculation to use was being changed hourly, so it has loads of commented versions littered all over the place, "Change it to this. It should be *2 not *3. Change it back to the original. *3 again. No, wait. *2)

  • Dave (unregistered) in reply to Christian
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.

    I tend to agree, but that's a very different case to that mentioned in the article:

    The Article:
    solely to duplicate the behavior
  • Xeromal (unregistered) in reply to DonaldK

    University all over again. :(

    Cogo, I had fun in the Cogo line today.

  • Not sure if Fry or just Philip (unregistered)

    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

  • airdrik (cs) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

    Oh, now that makes perfect sense, thanks!

  • Playoffs? (unregistered) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

    Magic Number = T - W - L

    where T is the total number of games in the season A is the number of games won by the team for which you are trying to calculate the magic number. B is the number of games lost by the team for which you are trying to calculate the magic number against.

    Source 1 Source 2

    That being said, it's way to early to start talking playoffs

  • operagost (cs)

    I am not a real programmer, so I don't work in C/C++ and didn't realize that this was legal in any languages. The last time I tried this it wouldn't compile. It was probably something esoteric like DEC BASIC.

  • WhiskeyJack (cs) in reply to Nick
    Nick:
    199 - clearly they are zero based arrays, and the max line length is 200 chars.

    Now if that line is sent elsewhere, then it is going to be bundled into a buffer. You will need an overhead for the message type, and the length of the text being sent. I would suggest that is 2 bytes for the message, and 4 bytes for the length. Or 4 and 2.

    Hence the 6.

    Would be better if that was a constant in its own right.

    e.g

    max_line = 199 protocol_size = 6 message_size = max_line + protocolsize

    You beat me to it, I was just thinking that's probably how I would see it appear in my code if it were to appear at all.

    But a better approach would be to declare a struct for the particular message type including the header block (message type, message length) and then do a sizeof() to calculate the size instead of hard-coding it to 205.

  • cellocgw (cs) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Which reminds me of a MatLab WTF: everybody, including me, uses _foo_ and _bar_ as throwaway variables. Well, just try that in MatLab, and then try to call their function to draw a bar plot, which is named, you guessed it, "bar" . Hilarious subscript errors ensue.
  • Karl (unregistered)

    C'mon guys it is staring you right in the face! How come nobody got it yet?

    // Sanity check

    If you are a sane person, when you look at the next line of code you will immediately delete it. Nobody has yet, therefore you and all your peers are insane.

  • Frank (unregistered) in reply to snoofle
    snoofle:
    Severity One:
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.
    Would you mind giving an example where a non-random random number makes sense?
    If you want to write a test where you need predictable results, then you'll need to know the "random" inputs in advance.
    Almost got there snoofle.

    Everyone should know the answer to this question. If you don't, you're Doing It Wrong. (Or never worked with random numbers.)

    Think about your workflow. You write software. You test it. It goes live. Someone finds a bug. You fix it. You test it again.

    What is the goal of that last test?

    Hmmm?

    Are you sure?

    If you answered "to confirm the bug is fixed" you lose. Well you get half points, which is 50%, which is an F in most classes.

    The answer is "to confirm the bug is fixed and to ensure no new bug is introduced, or other old bug came back".

    How do you do that? You save the results of the "before fix" test and compare them with the "after fix" test. Only one thing should have changed. The badness should now be goodness. No other new badness.

    Now, if you have random numbers in the mix, most likely every run will be different. So how can you compare the output? Huh??

    See, if you'd ever done proper testing against random numbers, you'd know you have to generate a known repeatable random number (or sequence) during this type of testing.

  • DaveK (cs) in reply to Gazzonyx
    Gazzonyx:
    TRWTF is that there isn't a comment on the magic numbers there. Not that there is anything wrong with something like this, but it should be documented. For instance, this is one of my commits to Samba :
    Good stuff. Here's your next one:
    [...] /* domain/username%password */ const int max = MAX_DOMAIN_SIZE + MAX_USERNAME_SIZE + - MOUNT_PASSWD_SIZE + 2; + /* Oops. CVE2012-xxx-yyy */ + MOUNT_PASSWD_SIZE + 3; [...]
  • DaveK (cs) in reply to DaveK
    DaveK:
    Gazzonyx:
    TRWTF is that there isn't a comment on the magic numbers there. Not that there is anything wrong with something like this, but it should be documented. For instance, this is one of my commits to Samba :
    Good stuff. Here's your next one:
    [...] /* domain/username%password */ const int max = MAX_DOMAIN_SIZE + MAX_USERNAME_SIZE + - MOUNT_PASSWD_SIZE + 2; + /* Oops. CVE2012-xxx-yyy */ + MOUNT_PASSWD_SIZE + 3; [...]
    Oh, don't bother, I see someone already caught it for you. Heh.

    <span style="color:white;">(I also see it's not directly used to size a buffer anyway.)</span>

  • Loren Pechtel (cs) in reply to AGray
    AGray:
    Constants in a class may or may not be a WTF - I'd honestly rather deal with a constant defined at the class level (preferably, in a Constants region) where I can easily find, identify, and maintain it, than have to sift through a bunch of code to find a method-level constant.

    The value of that constant though...I think that's TRWTF.

    Captcha: enim - must be Eminem's little brother.

    Yup. I've declared plenty of constants in classes. They're not applicable outside the class but a constant is much better than a magic number in the code.

    Nick:
    199 - clearly they are zero based arrays, and the max line length is 200 chars.

    Now if that line is sent elsewhere, then it is going to be bundled into a buffer. You will need an overhead for the message type, and the length of the text being sent. I would suggest that is 2 bytes for the message, and 4 bytes for the length. Or 4 and 2.

    Hence the 6.

    Would be better if that was a constant in its own right.

    e.g

    max_line = 199 protocol_size = 6 message_size = max_line + protocolsize

    Agreed. If the reason for the math isn't self-evident you should do something like this.

  • Not sure if Fry or just Philip (unregistered) in reply to airdrik
    airdrik:
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

    Oh, now that makes perfect sense, thanks!

    Since there seems to be a misunderstanding, here's my point: Don't rely on the compiler to do your math. Show what you meant in the comment, and store the calculated result in the const. On the other hand, generic variables like "foo" and "bar" are the most evil variable names ever. While they're perfectly acceptable in short and meaningless examples, they should never, ever appear in production code. Except when they mean something, like spacebar or meter bar.

  • WordCrawler (unregistered) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    airdrik:
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

    Oh, now that makes perfect sense, thanks!

    Since there seems to be a misunderstanding, here's my point: Don't rely on the compiler to do your math. Show what you meant in the comment, and store the calculated result in the const. On the other hand, generic variables like "foo" and "bar" are the most evil variable names ever. While they're perfectly acceptable in short and meaningless examples, they should never, ever appear in production code. Except when they mean something, like spacebar or meter bar.

    Oh yeah, and don't forget to maintain that comment when you change the number from 205 to 206!

    CAPTCHA: damnum = damn number

  • Jack (unregistered) in reply to Dave
    Dave:
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.

    I tend to agree, but that's a very different case to that mentioned in the article:

    The Article:
    solely to duplicate the behavior, but with tons of bugs

    FIFY (if history is any indicator)

  • Calli Arcale (unregistered) in reply to Frank
    Frank:
    The answer is "to confirm the bug is fixed and to ensure no new bug is introduced, or other old bug came back".

    Well, that's what you hope to do. More often, you'll find that although the bug was fixed, it has now broken something else. Or it is only fixed in condition A, but in condition B it remains broken. Or the bug didn't break anything else at all, but you've stumbled upon something broken that nobody had noticed yet, possibly because the bug you fixed was concealing it.

    I actually get a little worried when regression testing always passes. I find myself wondering whether or not the testing is adequate.

  • Dan Minjoc (unregistered) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    airdrik:
    Not sure if Fry or just Philip:
    Really guys, use the fucking comments if you want to explain magic numbers.

    // length is 199 (because of foo) + 6 (because of bar) public final static or whatever length = 205;

    Even better, use javadoc.

    Oh, now that makes perfect sense, thanks!

    Since there seems to be a misunderstanding, here's my point: Don't rely on the compiler to do your math. Show what you meant in the comment, and store the calculated result in the const. On the other hand, generic variables like "foo" and "bar" are the most evil variable names ever. While they're perfectly acceptable in short and meaningless examples, they should never, ever appear in production code. Except when they mean something, like spacebar or meter bar.

    Disagree. The compiler will automatically evaluate the expressions. Why decrease code readability for no benefit?

    Which would you rather have?

    const uint32 NUM_SEC_IN_DAY = 60 * 60 * 24; const unit32 NUM_SEC_IN_DAY = 86400;

    Both are correct, but the first one shows exactly where the calculation is coming from.

  • Jack (unregistered) in reply to Not sure if Fry or just Philip
    Not sure if Fry or just Philip:
    Since there seems to be a misunderstanding, here's my point: Don't rely on the compiler to do your math. Show what you meant in the comment, and store the calculated result in the const.

    I tend to disagree. I trust the compiler's math way more than most developers'.

  • Harrow (unregistered) in reply to operagost
    operagost:
    I am not a real programmer, so I don't work in C/C++ and didn't realize that this was legal in any languages. The last time I tried this it wouldn't compile. It was probably something esoteric like DEC BASIC.
    Ah yes, I recall whiling away many happy hours writing DEC BASIC. In fact, I give DEC BASIC full credit for making me the person I have become today. I would explain more but Doctor says I'm not supposed to even use the computer at all while I'm in here.

    -Harrow.

  • C-Octothorpe (cs) in reply to Frank
    Frank (Captain Obvious):
    snoofle:
    Severity One:
    Christian:
    in my opinion it makes perfect sense to encapsulate something like a random-number generator in your own class, this way you can replace this component with one that returns a "random" number which you can control in your unit-tests.
    Would you mind giving an example where a non-random random number makes sense?
    If you want to write a test where you need predictable results, then you'll need to know the "random" inputs in advance.
    Almost got there snoofle.

    Everyone should know the answer to this question. If you don't, you're Doing It Wrong. (Or never worked with random numbers.)

    Think about your workflow. You write software. You test it. It goes live. Someone finds a bug. You fix it. You test it again.

    What is the goal of that last test?

    Hmmm?

    Are you sure?

    If you answered "to confirm the bug is fixed" you lose. Well you get half points, which is 50%, which is an F in most classes.

    The answer is "to confirm the bug is fixed and to ensure no new bug is introduced, or other old bug came back".

    How do you do that? You save the results of the "before fix" test and compare them with the "after fix" test. Only one thing should have changed. The badness should now be goodness. No other new badness.

    Now, if you have random numbers in the mix, most likely every run will be different. So how can you compare the output? Huh??

    See, if you'd ever done proper testing against random numbers, you'd know you have to generate a known repeatable random number (or sequence) during this type of testing.

    Wow, ground-breaking stuff you got there... So, you're telling me that when I fix a bug, I need to make sure I don't break everything else? Thank goodness you were here to tell everyone in such a condescending tone...

  • Joe (unregistered) in reply to Frank
    Frank:
    Now, if you have random numbers in the mix, most likely every run will be different. So how can you compare the output? Huh??

    See, if you'd ever done proper testing against random numbers, you'd know you have to generate a known repeatable random number (or sequence) during this type of testing.

    You run the test 10 billion times so that you know you're testing every random 32-bit number (to within 5%) that might come up in production.

    This also gives the advantage of never finding another problem during your career, and/or inflating the "number of tests passed" metric that you get a bonus on.

    --Joe

  • Zylon (cs) in reply to Vamp
    Vamp:
    I have done that with constants before. For example timeouts or similar:

    const int TWO_MINUTE_CONSTANT = 2 * 60;

    Makes it easier to read for me later.

    So, in case at some point in the future you forget what "TWO MINUTES" means?

Leave a comment on “Sanity Check”

Log In or post as a guest

Replying to comment #:

« Return to Article