• anonymous (unregistered) in reply to Anonypony
    Anonypony:
    anonymous:
    Yes, you are missing something. Here is a code example:
    for (i = 0; i < 100; ++ i) {
        //code
    Question: At a high level, without taking the time to examine all of the code inside the loop, what does the loop do?

    Answer: Not the obvious (iterate i from 0 to 99). Actually, you must look through all the code inside the loop to see whether there's a break statement or whether it changes the value of i.

    Unless... your coding standards say that you can't use break or change a loop counter inside the loop, and you strictly adhere to them (or at least put a comment at the top of the loop saying what you did, when it's not obvious).

    Oh, I see you're one of those people. The same kind of person who says that in C-styled languages CURLY BRACES MUST ALWAYS ALWAYS ALWAYS BE USED! Because, well, someone MIGHT ADD A LINE! And get really CONFUSED by the indent! And then the loop/conditional MIGHT NOT WORK! And then, OMG AND THEN! When they don't even BOTHER TESTING, they don't find out that it DOESN'T WORK! OH EM GEE!

    Anyone who is willing to make changes to a section of code without first reading and understanding it should immediately change jobs to telephone sanitation. They are clearly ill-suited mentally to do anything else.

    The "if statements must always use braces to prevent errors" crowd is easily the worst of the "save idiots from themselves" bunch. It's accepting that someone cannot read and understand two lines of code before making a change, AND that they don't even bother testing their change. In short: morons enabling morons.

    Sorry for the rage, but I deal with this at my job every day. Making rules just so the morons around don't screw up is (1) an intractable problem, and (2) going to drive everyone else away.

    See also: early return (goto in disguise!) and exceptions (scary!).

    Not really. Every programmer makes idiot mistakes now and then. Coding standards are supposed to keep you away from the pitfalls and danger zones, but they shouldn't be hard and fast laws that can never be violated. As I said, if you really need to do something that violates your coding standards, then it should be thoroughly commented - and don't whine if a moron somehow comes along and screws it up later.

    In general, if your coding standards are sensible, it'll be pretty rare when you run into a situation where you really can't write code that performs just as efficiently without breaking them.

  • (cs)

    The wrong image was used with this article. The correct image would be something from the episode of Star Trek TNG entitled "The Ensigns of Command" where Picard gets beaten repeatedly by a several thousand page treaty with the Sheliak. The ONLY episode in all of Star Trek where the Captain dusts off the ship's plaque.

    Riker: "You enjoyed that." Picard: "You're damned right I did."

  • (cs) in reply to anonymous
    anonymous:
    In general, if your coding standards are sensible, it'll be pretty rare when you run into a situation where you really can't write code that performs just as efficiently without breaking them.

    I think that's the point that was attempted to be made with this article: coding standards aren't always sensible.

  • Jay (unregistered) in reply to ztrem
    ztrem:
    For all of you trying to find "clever" solutions based on exiting the loop: They'd almost certainly also be against the standards.

    If breaks are prohibited, I'm sure that setting the conditional in a for loop is also prohibited. There's NO WAY they would allow a try/catch to do program logic. Goto would probably get him fired on the spot.

    The only one I saw that MIGHT be allowed is factoring the loop into its own method and then returning mid-loop. It depends on how the rule is worded.

    The flaw to your reasoning here is that you're assuming that the coding guidelines are well-thought out and consistent, and that enforcement is based on the spirit of the rules rather than mindlessly following the rules to the letter.

    In real life, none of those assumptions are likely to be valid. Very likely you can find some obscure language feature that they forgot to ban, and if there is no rule against it, then, by definition, you can use it. "But that would be stupid" is not a thought that occurs to the legalist. The only question is, "Does it violate the rules?"

  • Aatch (unregistered) in reply to Paul Neumann
    Paul Newman:
    In which language is a for loop not compiled to a while loop?

    That's actually tricky because the semantics aren't actually identical in the presence of continue.

    In a for loop, using continue will cause a jump to the post-block operation (e.g. the i++) then continue the loop back from the conditional. If a while loop, it will just jump back to the conditional. Much of the time the generated code will be identical, but non-trivial loops, non-trivial for loops in particular, can generate different code. The conversion is not always a mechanical process.

  • Jay (unregistered)

    Once when I wrote coding standards for a development team, I included a clause that said, If you believe one of these rules to be counter-productive in a particular program, you may break the rule provided that you include a comment explaining why you found it necessary to break the rule. If writing the comment is more trouble than obeying the rule, then obey the rule.

  • Jay (unregistered)

    I think many stupid rules come about because someone says, "It is usually better to do X than to do Y. Therefore, we will make a rule requiring people to always do X and never do Y."

    Stated that way, perhaps the flaw in the reasoning is obvious: Just because something is USUALLY better does not mean that it is ALWAYS better. But people rarely state it that way.

    Stupid rules are enforced because someone is put in charge of enforcing the rules whose only incentive is to make sure that the rules are enforced, not that the organization's overall goals are reached.

    It is usually pointless to say to the policeman, "Yes, I went through the red light. But presumably the point of traffic lights is to prevent collisions, and I could see that there were no other cars for at least a mile in any direction, so there was no point sitting here waiting for the light to change. Indeed, if I waited another car might have come along and the danger of an accident would have been greater." The policeman's response is likely to be, "That may be so, but the law says you cannot go when the light is red. Here is your ticket."

  • (cs) in reply to Kivi
    Kivi:
    luptatum:
    Matt Westwood:
    Not putting too fine a point on it, from recent experience it turns out they can't design user website journeys for beans.
    But why do the beans need user website journeys in the first place?
    Yes, that's really an edge case. Honestly, you can't fault the designers for leaving that one out.

    I mean really. Beans?

    Yeah beans. Heard of them? They make you fart.

  • Peter (unregistered) in reply to opto
    opto:
    None of such stories ever fucking happened - admit it. You're boring. What the fuck am I even doing here...
    Perhaps you get some perverse pleasure in whining about how much you hate to be here? There is, of course, a simple action you could take to make things better for yourself.
  • Anonypony (unregistered) in reply to RangerNS
    RangerNS:
    Anonypony:
    The "if statements must always use braces to prevent errors" crowd is easily the worst of the "save idiots from themselves" bunch. It's accepting that someone cannot read and understand two lines of code before making a change, AND that they don't even bother testing their change. In short: morons enabling morons.

    Granting that is a bad reason, there are at least two good reasons:

    1. Reading the code, you exert less effort if you always have the same ending token.
    2. Reading diff's is easier, because the noise of the closing and ending braces changing, well, won't exist.

    The second reason is more important than the first.

    I'll agree with the second reason, and if it were given as a cause to require braces I likely wouldn't have any argument. Sadly that's the first time I've ever seen it presented (at work or in books). It's always a purported "less chance of mistakes".

    The first reason I think has less weight, but probably depends on the person somewhat. I think

    if (isCommercialAccount)
        DoTheThing();
    
    if (dayOfTheWeek == Days.Friday)
        BeLessSad();
    

    is quicker to grok than (our coding standard):

    if (isCommercialAccount)
    {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday)
    {
        BeLessSad();
    }
    

    but that this is a good middle ground:

    if (isCommercialAccount) {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday) {
        BeLessSad();
    }
    

    PS: Wow, you'd think this site would handle code blocks better.
    inside of the

    ?  Cool.

  • Peter (unregistered) in reply to golddog
    golddog:
    I believe the term is, "baited breath."
    Actually, "bated breath" is the right usage. I can't believe that no-one else has noticed this mistake.
    Jeff Ong:
    No, it's bated, as in "abated." It's an archaic truncation which has become idiomatic.
    boppןob:
    You believe wrong, it's correct in the article.
    ceiswyn:
    Only if you've eaten a bunch of worms in the hope that trout will swim into your mouth.
    nisl:
    I believe you are incorrect. Grammar Nazi fail.
    Mozzis:
    "Bated" is correct: it is an archaic short form of "abated"
    Friedrice The Great :
    "Bated breath," shortened version of "abated breath". "Baited breath" is for catching fish.
    Tristan:
    Nope, the article is right, it's bated breath. It's a shortened form of abated, meaning reduced.
    Oh.
  • gnasher729 (unregistered) in reply to XXI
    XXI:
    Writing code assuming that no one will ever do a clueless modification that might subtly break things is pretty much the best way to get a horrible codebase

    but then again, that's what unit tests are for...

    Allowing people to make clueless modifications without code reviews is the best way to get a horrible codebase.

  • (cs) in reply to chubertdev
    chubertdev:
    opto:
    Your stories are fictional, to the true meaning of that word: they're not just changed to hide identities of people and locations, but they never happened!

    There's always some smartass Derek who, normally working in sales or shipping for 14 fucking bucks an hour, suddenly is smarter than anyone around and happens to be expert in some programming language, happens to be able to find and open the source code, find bugs, fix them and prove his badass skills. Then he gets unfairly fired, because he went against the company policy.

    None of such stories ever fucking happened - admit it. You're boring. What the fuck am I even doing here...

    I take most of the details of the stories on here with a grain of salt. The editors take "anonymizing" to a whole new level. They change the details and stories to the point where the comments are mostly about details that are most likely completely fictional, such as releasing directly to prod without a code review, but then having one after.

    Who said anything about releasing to production? All it said was that the code was fixed and checked in. And Reverted. And Checked in differently. And Reverted. And checked in differently yet again.

    BTW: some submissions are only a couple of lines and we really have to fill in the details from our own similar experiences. In this case, the submission was fairly detailed, and all I really added was the whole resistance-is-futile prelude. Also, sometimes folks expressly ask us to distort the submission, presumably to protect themselves; but we ALWAYS keep the central WTF in-tact!

  • Standards (unregistered) in reply to Anonypony
    Anonypony:
    RangerNS:
    Anonypony:
    The "if statements must always use braces to prevent errors" crowd is easily the worst of the "save idiots from themselves" bunch. It's accepting that someone cannot read and understand two lines of code before making a change, AND that they don't even bother testing their change. In short: morons enabling morons.

    Granting that is a bad reason, there are at least two good reasons:

    1. Reading the code, you exert less effort if you always have the same ending token.
    2. Reading diff's is easier, because the noise of the closing and ending braces changing, well, won't exist.

    The second reason is more important than the first.

    I'll agree with the second reason, and if it were given as a cause to require braces I likely wouldn't have any argument. Sadly that's the first time I've ever seen it presented (at work or in books). It's always a purported "less chance of mistakes".

    The first reason I think has less weight, but probably depends on the person somewhat. I think

    if (isCommercialAccount)
        DoTheThing();
    
    if (dayOfTheWeek == Days.Friday)
        BeLessSad();
    

    is quicker to grok than (our coding standard):

    if (isCommercialAccount)
    {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday)
    {
        BeLessSad();
    }
    

    but that this is a good middle ground:

    if (isCommercialAccount) {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday) {
        BeLessSad();
    }
    

    PS: Wow, you'd think this site would handle code blocks better.
    inside of the

    ?  Cool.

    I really hate the braces on their own line thing. The important point of the block is not that it's in a block, but that it is tied to a condition. I want my ending braces to match up to the reason for the indentation in the first place, and avoid the starting brace that has to be there anyway. Brace lines are just noise.

    I do agree with the brace everything approach though. It's just less hassle to not worry about it ever. When someone checks in a small change, but formats the entire file, it's annoying to check diffs (especially since you can't avoid it by ignoring whitespace in the diff).

  • (cs) in reply to snoofle
    snoofle:
    chubertdev:
    opto:
    Your stories are fictional, to the true meaning of that word: they're not just changed to hide identities of people and locations, but they never happened!

    There's always some smartass Derek who, normally working in sales or shipping for 14 fucking bucks an hour, suddenly is smarter than anyone around and happens to be expert in some programming language, happens to be able to find and open the source code, find bugs, fix them and prove his badass skills. Then he gets unfairly fired, because he went against the company policy.

    None of such stories ever fucking happened - admit it. You're boring. What the fuck am I even doing here...

    I take most of the details of the stories on here with a grain of salt. The editors take "anonymizing" to a whole new level. They change the details and stories to the point where the comments are mostly about details that are most likely completely fictional, such as releasing directly to prod without a code review, but then having one after.

    Who said anything about releasing to production? All it said was that the code was fixed and checked in. And Reverted. And Checked in differently. And Reverted. And checked in differently yet again.

    BTW: some submissions are only a couple of lines and we really have to fill in the details from our own similar experiences. In this case, the submission was fairly detailed, and all I really added was the whole resistance-is-futile prelude. Also, sometimes folks expressly ask us to distort the submission, presumably to protect themselves; but we ALWAYS keep the central WTF in-tact!

    http://thedailywtf.com/Comments/Coding-Practices-MUST-Be-Followed.aspx?pg=2#415698

  • (cs)

    That being said, there definitely is a fine art in anonymization, and I try to not let the details that are changed be the gospel truth of the story.

    I do hate when people here leave comments about a very precise detail that was most likely changed to protect the innocent, such as assuming a person's heritage based on their obviously fake name.

  • uxor (unregistered) in reply to Worf
    Worf:
    If the new program ran in under a minute - won't people get suspicious that it didn't work? After all, the old one took half an hour, the new one an hour.
    Wow, reading comprehension fail is rampant today. The old one took five minutes TO RUN, the half-hour was for manually massaging the data. So you comment on an article without first understanding it. I'll bet you change other people's code the same way.
  • (cs)

    “Comments in response to another comment must quote the latter comment. Please see 'User-Submitted Content Practices' document, 'Comments' on page 23, part 2, paragraph 2.”

  • Barf4Eva (unregistered)

    Interesting to note... that had they not had those coding practices in there, the best this developer would have given us was a break statement. Ergo, all the rules resulted in forcing the developer towards the best solution!

    RESISTANCE IS FUTILE!

  • jonny_q (unregistered) in reply to It's Pat
    It's Pat:
    Joel:
    See? Once he followed the specified coding practises, he was able to produce an optimal solution for the users. When he insisted on not following the coding guidelines suboptimal fixes resulted. Another win for guidelines!

    I was actually thinking this. Instead of having to make a half-arsed fix to a half-thought out solution, he made an efficient solution that cut the processing time from an hour or more down to a couple of minutes.

    Granted, I think being forced not to break from a loop is pretty stupid. And quibbling between using a for-each verse a while loop is also pedantic.

    If you're going to "break", "continue", or "return" from inside a loop, and if I'm the one with the rulebook, the rule would have to be two lines of comments, and the loops itself can't be longer than 50 lines so it all fits on the screen most people's editor so you can see at a glace where the jump is. Otherwise, yeah, stick with the top-to-bottom flow.

  • Andrew (unregistered)

    Although I happily break from for loops I have been caught out doing it. Say I wanted to look through a number of files until I find something. Here's some rough C code:

    for (i = 0; i < number_paths; ++i) { FILE *fp = fopen(filepaths[i], "r");

    if ( /* search fp for data */ ) break;
    
    fclose(fp);
    

    }

    When I first did something like this it actually works. It returns the correct result and does so moderately better that going through the entire list of file paths.

    But as the program kept running it would start to act odd. It took me a long time to spot this error because the application's failure wasn't actually in this part of the code.

    Obviously such a small code snippet makes the issue really obvious, but when that for loop was about the size of the screen it was easy for me to forget that I was breaking from a loop without first closing a file.

    I'm not against breaks in for loops but I can see why it might leave a sour taste in people's mouths.

  • Norman Diamond (unregistered) in reply to Andrew
    Andrew:
    Although I happily break from for loops I have been caught out doing it. for (i = 0; i < number_paths; ++i) { FILE *fp = fopen(filepaths[i], "r");
    if ( /* search fp for data */ ) break;
    
    fclose(fp);
    

    }

    Oops. Your new roommates are going to be Edward Snowden and Chelsea Manning.

    TRWTF is that coding practices didn't include code walkthroughs. EVERYONE's code needs extra eyes.

  • Shark8 (unregistered) in reply to Paul Neumann
    Paul Neumann:
    In which language is a for loop not compiled to a while loop?

    Probably Ada.

    The For loop is indexed off of the array or subtype that you're working with and cannot modify the index. (In Ada 2012 there's For loops on collections, but the basic idea remains the same.) In the While loop the condition may be freely modified in the body of the loop itself.

    So there's a fundamental difference there. (Though, granted, it may use the same sort of code generation on both loops -- Ada compilers have a reputation for being quite clever.)

  • Eep (unregistered) in reply to XXI

    Have you seen how most people write unit tests?

  • D (unregistered) in reply to On a Break
    On a Break:
    nitePhyyre:
    Also, where does this idea that breaking out of a loop is bad come from? It seems like absolute non-sense to me. In what world does looping and checking variables against conditions when you know you've already found what you are looking for make any lick of sense?
    The issue is probably the "break" statement itself.

    It's not always obvious what it's going to do due to nested loops etc. When one of them gets unrolled or removed later, there is a higher chance that a break gets left in and breaks the next thing up the chain than if you werne't using break. That's why I never* use them in loops.

    Presumably they want you to pull the loop into its own method and return early.

    return_type get_result_from(list)
    {
      foreach(thing, list) {
        result = check_stuff(thing);
        if (got_answer) return result;
      }
      return bad_result;
    }
    
    * "Never" means "unless I really need to"

    Methods on page 22, part 4, paragraph 1

    A method should have a single exit point.

    You're clearly not familiar with the guidelines ;)

  • Dude (unregistered) in reply to Anonypony
    Anonypony:

    Sorry for the rage, but I deal with this at my job every day. Making rules just so the morons around don't screw up is (1) an intractable problem, and (2) going to drive everyone else away.

    See also: early return (goto in disguise!) and exceptions (scary!).

    As Carlo Cipolla once said: you cannot defend against morons, because morons are very witty. Well, he was talking about idiots, but the reasoning still works. There are so many ways of being stupid that you cannot cover all possible cases.

    captcha: dolor = pain, how appropriate!

  • Hasse (unregistered) in reply to Jay
    Jay:
    I think many stupid rules come about because someone says, "It is usually better to do X than to do Y. Therefore, we will make a rule requiring people to always do X and never do Y."

    Stated that way, perhaps the flaw in the reasoning is obvious: Just because something is USUALLY better does not mean that it is ALWAYS better. But people rarely state it that way.

    Stupid rules are enforced because someone is put in charge of enforcing the rules whose only incentive is to make sure that the rules are enforced, not that the organization's overall goals are reached.

    It is usually pointless to say to the policeman, "Yes, I went through the red light. But presumably the point of traffic lights is to prevent collisions, and I could see that there were no other cars for at least a mile in any direction, so there was no point sitting here waiting for the light to change. Indeed, if I waited another car might have come along and the danger of an accident would have been greater." The policeman's response is likely to be, "That may be so, but the law says you cannot go when the light is red. Here is your ticket."

    This police story happend to a friend of mine. To avoid a collition from someone behind he drowe through red. He did not got a fine.

  • sephectja (unregistered) in reply to Walky_one

    This generally results in commends dotted over the place in our system with stuff like 'OH GOD, I FEEL DIRTY FOR THIS HACK, SORT OUT WHEN WE HAVE TIME' only to come back to it a year or so later, and it hasn't been touched, lol

  • QJo (unregistered)

    I'm going to add my weight to the opinion that using break to exit a for loop is in general bad practice. Even if you can program the damn thing right (a pretty big if a lot of the time) then ensuring that the maintenance moron following you actually understands what you're doing requires copious documentation.

    There was a programming course I went on which gave us the following rules:

    a) Do you know exactly how many times you need to iterate? (This includes where the indices are variables which are not amended in the body of the loop.) Then use a For loop.

    b) Is the condition on which you're looping something which is indeterminate when starting the loop? (This includes the case where the condition for exit may be calculated during the execution of the loop.) Then use a While loop.

    If you are breaking out of the for loop using a break then you should be using a while, and rather than use break, set a flag and test it when re-entering the loop.

    But what if I want to break out of the loop half way through the execution of that loop? Then you may do well to re-analyse your process, but in such a circumstance I would nest the section after where you want to break out inside an if statement on that same flag signalling end of processing.

    And if the code inside the loop is so long and complicated that you can't see the top and bottom of it on the same page, then break out what's inside it into a separate method / procedure / subroutine / function / whatever.

    I suspect that the guidelines in question arose from certain misapplication of break statements, and insistence on using a while loop on a specifically-incremented variable at the bottom, such as:

    int n = 0;
    while (n < max) {
      do some stuff
      if (!do we need to do the rest of this loop) {
         continue;
      }
      do some more stuff
      n++;
    }
    

    ... for which the developer needs to be given the opportunity to take up a refresher course.

    Neither of these things should detract from the true solution (as explained in the article) that you really should not be looping through a list to find an matching element, you should indeed be using a lookup table.

  • (cs) in reply to Anonypony
    Anonypony:
    RangerNS:
    Anonypony:
    The "if statements must always use braces to prevent errors" crowd is easily the worst of the "save idiots from themselves" bunch. It's accepting that someone cannot read and understand two lines of code before making a change, AND that they don't even bother testing their change. In short: morons enabling morons.

    Granting that is a bad reason, there are at least two good reasons:

    1. Reading the code, you exert less effort if you always have the same ending token.
    2. Reading diff's is easier, because the noise of the closing and ending braces changing, well, won't exist.

    The second reason is more important than the first.

    I'll agree with the second reason, and if it were given as a cause to require braces I likely wouldn't have any argument. Sadly that's the first time I've ever seen it presented (at work or in books). It's always a purported "less chance of mistakes".

    The first reason I think has less weight, but probably depends on the person somewhat. I think

    if (isCommercialAccount)
        DoTheThing();
    
    if (dayOfTheWeek == Days.Friday)
        BeLessSad();
    

    is quicker to grok than (our coding standard):

    if (isCommercialAccount)
    {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday)
    {
        BeLessSad();
    }
    

    but that this is a good middle ground:

    if (isCommercialAccount) {
        DoTheThing();
    }
    
    if (dayOfTheWeek == Days.Friday) {
        BeLessSad();
    }
    

    I totally disagree. The middle examples are the easiest to read, and your middle ground ones are the worst.

  • QJo (unregistered) in reply to sephectja
    sephectja:
    This generally results in commends dotted over the place in our system with stuff like 'OH GOD, I FEEL DIRTY FOR THIS HACK, SORT OUT WHEN WE HAVE TIME' only to come back to it a year or so later, and it hasn't been touched, lol

    Another practice is to add @TODO into the code at the point where you now you need to return to it to do it properly, and set up your IDE to search for such tags and alert you to them. Every so often you leave yourself time to do "maintenance".

    You mean you don't have the freedom to organise your own working practices so as to allow a certain amount of time during the week (e.g half a day) for routine exercises like housekeeping and maintenance? There's TRWTF, right there.

  • Mike (unregistered)

    Coding standards

    How very 1990s. these days we hire people who kow what the fuck they are doing (or train them) and don't need coding standards. OUr coding standards doc is buried in some repository somewhere and hasn't been looked at forprobably over 5 years, in that time I have hired over a dozen developers and coding varience is tiny. The biggest problem is framework choice and whatever the latest way the workd is supposed to run according to the Java/M$ bods ie. which techs to adopt silverlight/html5/ajax/xaml/wpf/hibernate/odata etc etc etc.

  • anonymous (unregistered) in reply to Jay
    Jay:
    It is usually pointless to say to the policeman, "Yes, I went through the red light. But presumably the point of traffic lights is to prevent collisions, and I could see that there were no other cars for at least a mile in any direction, so there was no point sitting here waiting for the light to change. Indeed, if I waited another car might have come along and the danger of an accident would have been greater." The policeman's response is likely to be, "That may be so, but the law says you cannot go when the light is red. Here is your ticket."
    Wait, wait... if there were no other cars, where'd the cop car come from?
  • (cs) in reply to anonymous
    anonymous:
    Wait, wait... if there were no other cars, where'd the cop car come from?
    They are Unix afficionados and know how to use the mount command!
  • (cs)

    our client have a practice where we are not allowing to be using LINQ queries. this is because our client side architect is not yet learned LINQ. any case c# suck if you cannot use LINQ.

    best stick to high level language like java.

  • Svensson (unregistered) in reply to Hannes
    Hannes:
    Mike:
    Haha. How about set the loop conditional to a value that will stop it (say max + 1). I didn't call break but the condition in the for loop did :)

    My pre-predecessor actually manipulated the loop conditional inside the loop (setting it to value-1) based on some conditions... I'm just glad he apparently never heard of the goto statement.

    When I was in school in the early 80's, avoiding goto was a really hot topic. But some languages still in use in that era (FORTRAN 77, ALGOL 60) did not have a BREAK statement. They didn't need one - that is what GO TO is for.

    Since we were explicitly forbidden to use goto in our assignments, the recommended way to exit a loop early was to manipulate the variable values for the termination condition. This was considered "more readable" than "GO TO LOOPEND;"

  • A nony mousely yours (unregistered) in reply to anonymous
    anonymous:

    Yes, you are missing something. Here is a code example:

    for (i = 0; i < 100; ++ i) {
        //code
    Question: At a high level, without taking the time to examine all of the code inside the loop, what does the loop do?

    Answer: Not the obvious (iterate i from 0 to 99). Actually, you must look through all the code inside the loop to see whether there's a break statement or whether it changes the value of i.

    Unless... your coding standards say that you can't use break or change a loop counter inside the loop, and you strictly adhere to them (or at least put a comment at the top of the loop saying what you did, when it's not obvious).

    Oh man, your so wrong! Or missing the point?

    for item in haystack:
        if item == "needle": 
            break
    

    Why would a sane person continue looking at all the other "straws" in the "haystack" when he/she already found the "needle" he/she was looking for?

    Am I missing you applying irony or something?

    (Note: I threw in the "your" vs. "you are" to put some "oil on the fire".)

  • Breath Bater (unregistered) in reply to Mozzis
    Mozzis:
    "Bated" is correct:

    http://www.phrases.org.uk/meanings/bated-breath.html

    it is an archaic short form of "abated"

    I bated last night, thinking of Jessica Alba.

    Wait, what?

  • anonymous (unregistered) in reply to A nony mousely yours
    A nony mousely yours:
    anonymous:

    Yes, you are missing something. Here is a code example:

    for (i = 0; i < 100; ++ i) {
        //code
    Question: At a high level, without taking the time to examine all of the code inside the loop, what does the loop do?

    Answer: Not the obvious (iterate i from 0 to 99). Actually, you must look through all the code inside the loop to see whether there's a break statement or whether it changes the value of i.

    Unless... your coding standards say that you can't use break or change a loop counter inside the loop, and you strictly adhere to them (or at least put a comment at the top of the loop saying what you did, when it's not obvious).

    Oh man, your so wrong! Or missing the point?

    for item in haystack:
        if item == "needle": 
            break
    

    Why would a sane person continue looking at all the other "straws" in the "haystack" when he/she already found the "needle" he/she was looking for?

    Am I missing you applying irony or something?

    (Note: I threw in the "your" vs. "you are" to put some "oil on the fire".)

    Search methodAvg. caseEfficiency for...in150,000O(n) for...in...break75,000O(n) Binary search16O(log n) Hash table1O(1)

    ...now, what exactly did you say a sane person would do?

    Skipping the needles after the one you're looking for means you're looking at every needle that came before, which is almost just as stupid as looking at all of them.

  • This guy (unregistered)

    I don't see a problem with break's, but there is a way around it. Many think of the classical for (int i=0; i < 10; i++) and forget that you can actually check for more than just "i < 10)

    Here's a way to avoid break's, but it's less clear in my opinion.

    boolean wtf = true:; for (int i=0; i < 10 && wtf; i++) { if (a == b) { wtf = false; } }

  • bambam (unregistered)

    Ha Ha Ha! PHP rulez! You can specify how many nested levels to break or continue.

    for ($x=0; $x < 10; ++$x) {
       for ($y=0; $y < $x; ++$y) {
          if ($theskyisfalling) break 2;
       }
    }
    
  • millimoose (unregistered) in reply to Chelloveck

    I guess that's why the US needs to invade so many countries. Can't sit in one place too long because of the butt-cheek scratches inflicted by 1-ply TP.

  • anonymous (unregistered)

    I work in a coding house where the only code guideline I object to is that all functions returning non-void must have only and exactly one RETURN statement. I pointed out cases actually in the codebase where this means two or three temporary variables whose only function is to carry the result to the end of the function without falling into other cases, but nope; readability apparently requires exactly one entry and one exit point for any function.

    Considering they allow THROW statements wherever convenient, it can be a bit frustrating.

    So I forced them to, wherever a RETURN statement returns a non-constant value, it must be from a FINAL variable (i.e. one that can be initialized only once). It at least solved our frequent initialization errors caused by their strange practice.

  • A nony mousely yours (unregistered) in reply to anonymous
    anonymous:
    A nony mousely yours:

    Oh man, your so wrong! Or missing the point?

    for item in haystack:
        if item == "needle": 
            break
    

    Why would a sane person continue looking at all the other "straws" in the "haystack" when he/she already found the "needle" he/she was looking for?

    Am I missing you applying irony or something?

    (Note: I threw in the "your" vs. "you are" to put some "oil on the fire".)

    Search methodAvg. caseEfficiency for...in150,000O(n) for...in...break75,000O(n) Binary search16O(log n) Hash table1O(1)

    ...now, what exactly did you say a sane person would do?

    Skipping the needles after the one you're looking for means you're looking at every needle that came before, which is almost just as stupid as looking at all of them.

    A bit besides the point. You are making big assumptions about the problem we are trying to solve here. No one defined size of haystack or the number of needles to find. But hey, make up your own problem spec so we can argue endlessly. ;)

    When binary search is apropriate, use it. When a hash table is apropriate, use it. When a break is apropriate, use it.

    I completely disagree with the "break is evil" crowd. In many cases "break"ing out of a loop is perfectly legit. (Oh and don't let me get started about: "continue is evil".)

  • (cs)

    So someone checked it against the part of the coding-practices document that said HOW to use loops, but not the part that said when NOT to use them at all. They didn't see the forest for the trees, which is why bringing in new blood once in a while is a good idea. WTWTF?

  • jf (unregistered)

    So... if the rules didn't forbid him from using breaks inside a loop, or substituting a for loop for a while loop, he would have committed the 30 minute code and would have never bothered implementing the 1 minute hash based one?

    Yay for rules, I say!

  • paratus (unregistered) in reply to jf
    jf:
    So... if the rules didn't forbid him from using breaks inside a loop, or substituting a for loop for a while loop, he would have committed the 30 minute code and would have never bothered implementing the 1 minute hash based one?
    All the fucking idiots who keep repeating this are, well, fucking idiots. Like I said before:
    He’d just saved at least an hour for most people, if not more. Derek then began to dig further into the code, but before getting anywhere significant, an email hit his box
  • EmperorOfCanada (unregistered)

    My experience with "Best Coding practices" is usually one person has an idiosyncratic coding style that they then foist onto everyone else. This might be OK if that person had developed 90% of the code but often it is someone who is a terrible coder and I think creates the coding standard to make themselves feel that they are in control of the situation.

    The key being that while everyone else is coding they are politicking to promote their "Standard"

  • anonymous (unregistered) in reply to A nony mousely yours
    A nony mousely yours:
    anonymous:
    A nony mousely yours:

    Oh man, your so wrong! Or missing the point?

    for item in haystack:
        if item == "needle": 
            break
    

    Why would a sane person continue looking at all the other "straws" in the "haystack" when he/she already found the "needle" he/she was looking for?

    Am I missing you applying irony or something?

    (Note: I threw in the "your" vs. "you are" to put some "oil on the fire".)

    Search methodAvg. caseEfficiency for...in150,000O(n) for...in...break75,000O(n) Binary search16O(log n) Hash table1O(1)

    ...now, what exactly did you say a sane person would do?

    Skipping the needles after the one you're looking for means you're looking at every needle that came before, which is almost just as stupid as looking at all of them.

    A bit besides the point. You are making big assumptions about the problem we are trying to solve here. No one defined size of haystack or the number of needles to find. But hey, make up your own problem spec so we can argue endlessly. ;)

    When binary search is apropriate, use it. When a hash table is apropriate, use it. When a break is apropriate, use it.

    I completely disagree with the "break is evil" crowd. In many cases "break"ing out of a loop is perfectly legit. (Oh and don't let me get started about: "continue is evil".)

    To be honest, I didn't make anything up - all of my assumptions were lifted directly from the original story.
  • Heh (unregistered)

    Another case where the problem could have been solved simply by doing the work in a database. One UPDATE statement. I guarantee that will be easier to maintain than trying to explain to a "senior" dev what a HashMap is and how it works.

Leave a comment on “Coding Practices MUST Be Followed”

Log In or post as a guest

Replying to comment #415715:

« Return to Article