• (cs) in reply to anonymous
    anonymous:
    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.

    I consider that requirement a bad code smell. If your function is too "complex" to be readable with a break statement, then it's really just too long, and trying to do too much. DO ONE THING.

  • etymology nazi (unregistered) in reply to golddog

    The term is "bated breath" from "bate", meaning to stop, closest common modern cognate is probably "abate".

    It is supposed to imply holding one's breath in anticipation, not having stress-induced halitosis.

  • (cs) in reply to etymology nazi
    etymology nazi:
    The term is "bated breath" from "bate", meaning to stop, closest common modern cognate is probably "abate".

    It is supposed to imply holding one's breath in anticipation, not having stress-induced halitosis.

    Oh.

    Peter:
    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.
  • streaky (unregistered) in reply to Paul

    "Coding guidelines should be reviewed for the edge case scenarios before being made 'law' and should have notes for said edge cases that allow things to pass that don't quite fit."

    More importantly - developers should have enough common sense to be able to see instantly when the rules are nonsense. As for "Derek" - what he should have done is jumped up and down on somebody's head after revert #2.

  • (cs)

    Was the Coding Practices document under version control? Seems like one answer would be to change the document, then implement your fix..

    Of course, a better answer is to simply delete the damned document in the first place. If a Coding Standards document is more than about 1 maybe 2 pages long then it's time to delete it and try again.

  • (cs) in reply to XXI

    "...even though it's nobody's fault."

    Of course it is somebody's fault. It is the fault of the last person to make a change to the code while ignoring the morass it had become.

    As professional developers we run across a lot of crap every single day. It's our job to make it right, not add to the mess.

    Imagine a bridge engineer that is told to add a new strut to a an existing bridge. He goes out, survey's it and determines that the bridge will likely collapse within a few years. Should that engineer ignore the problem and simply add the strut? No, he needs to point out the problem along with documenting that he pointed it out and the resulting answer.

    This is why our profession has zero credibility and why real engineers and architects get pissed off when we use those titles. Most of us aren't engineers or architects. Just dumb ass pretenders using fancy titles while having little to no clue WTF we are doing.

    I would honestly vote for the title of Programmer to become something only bestowed on people that pass standard tests of competence. Similar to engineers, architects, lawyers and doctors.

    /soapbox.

  • (cs) in reply to clively
    clively:
    Imagine a bridge engineer that is told to add a new strut to a an existing bridge. He goes out, survey's it and determines that the bridge will likely collapse within a few years. Should that engineer ignore the problem and simply add the strut? No, he needs to point out the problem along with documenting that he pointed it out and the resulting answer.

    http://en.wikipedia.org/wiki/List_of_bridge_failures

  • Joe (unregistered) in reply to clively
    clively:
    Imagine a bridge engineer that is told to add a new strut to a an existing bridge. He goes out, survey's it and determines that the bridge will likely collapse within a few years. Should that engineer ignore the problem and simply add the strut? No, he needs to point out the problem along with documenting that he pointed it out and the resulting answer.

    In fact, the bridge engineer would be legally liable if he signed off on faulty plans. That's why you have the whole concept of Professional Engineer certification, and Registered Professional Engineers. For public works such as bridges, you need a registered engineer to sign off, and when they do, they're taking some amount of liability for what happens next.

    clively:
    This is why our profession has zero credibility and why real engineers and architects get pissed off when we use those titles. Most of us aren't engineers or architects. Just dumb ass pretenders using fancy titles while having little to no clue WTF we are doing.

    I would honestly vote for the title of Programmer to become something only bestowed on people that pass standard tests of competence. Similar to engineers, architects, lawyers and doctors.

    Amen! Although, I suspect you'll find the ranks of those who achieve that title to be thin, just as they are for registered professional engineers.

    I hold a BSEE and have strong programming and computer architecture backgrounds. I've never passed (or even bothered to try to pass) the Professional Engineer certification, so I can't actually use the word "Engineer" in my job title. The law forbids it. I'm pretty sure "Architect" does not carry the same legal prohibition, and Architect is the job title I apply to myself.

    Pretty much everyone I work with is in the same boat, registration-wise. We have engineering degrees, and we do engineering (building complex computer chips, actually), but just about none of us is a registered professional engineer.

    The few RPEs that are out there generally don't do all the engineering themselves. They sign off on the plans put together and the work done by the rest of us. I suspect you'd end up in a similar situation for software engineering--a handful of registered professional software engineers deployed strategically where needed, and the rest of us still hacks.

  • coyo (unregistered) in reply to Barf4Eva

    The cost was high to get the minor speed improvement over using the break, an improvement that would not have been noticed by the users.

    The cost was a loss of time and unhappy customers. Not worth it for this case.

  • aaawww (unregistered) in reply to Trevor D'Arcy-Evans

    duh, why is not that string an enum or a constant?

  • Witmonger (unregistered)

    I don't know about the next 3 pages of comments, but this is the first TDWTF I've read that didn't have at least half of the commenting readers immediately bitching and yelling about inconsistencies in the story or writing style/quality/logic. I...I just don't even know what to do at this point. It's like a whole 'nother world.

    CAPTCHA: acsi Ack! See what can happen when we let ourselves enjoy something and don't nitpick it into oblivion?

  • GWO (unregistered) in reply to A nony mousely yours

    What would a certain person do? Express the loop invariant in appropriate place for the loop invariant...

    while(item != "haystack") item=collection.next();

    for(iter=container.begin(); (iter != container.end() && complex_condition_met == 0); ++iter){ frobnicate(*iter) complex_condition_met = do_complicated_calculation(*iter); }

  • AN AMAZING CODER (unregistered)

    I have to agree with earlier comments -- this WRT seems to focus on the idea that blindly following coding standards is dumb, but in reality forcing the developer to abide by coding standards force him to think about his solution further, which resulted in a much greater speed-up.

    So, who lost in this case?

  • AN AMAZING CODER (unregistered)

    I'm also curious about the development workflow used at the shop in question. This developer is making fixes, and checking the main line, then there's some ghost developer going through the code constantly reverting changes (and committing the revert!) that don't pass compliance?

    Why isn't the developer who broke compliance tasked with making their code compliant, and re-commiting it themselves?

    What happens when the change is reverted after

    It seems that if you're going to have compliance police that sits between the main line and developers, then developers should not be committing to the main line.

  • tego (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    I have to agree with earlier comments
    Clearly you didn't actually read the earlier comments.
  • AN AMAZING CODER (unregistered) in reply to tego
    tego:
    AN AMAZING CODER:
    I have to agree with earlier comments
    Clearly you didn't actually read the earlier comments.

    You're missing the point....badly.

    He thought his solution was good enough that not only did he commit it, but he shared the changes.

    Who on earth commits code, shares it, and then (immediately) tries to improve it?

  • ratis (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    He thought his solution was good enough that not only did he commit it, but he shared the changes.
    He'd made a significant improvement, and at that point didn't know if he'd be able to improve it further, or how long it would take to do so. Why punish the users by withholding what he'd already done?
    Who on earth commits code, shares it, and then (immediately) tries to improve it?
    Literally everyone in the world who releases software, or do you prefer to use programs that are perfect at version 1.0 and never updated?

    (As for the "immediately", do you really think that software companies take a holiday after releasing a product, or is it more likely that they have people working on version n+1 while version n is still in beta testing?)

  • suscipit (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    You're missing the point....badly.
    Another thing: if that's the point you were trying to make, you failed spectacularly. There's nothing in your previous posts that even hints that you think he shouldn't have committed anything until he was sure he had the right fix, you were pretty unambiguously saying "the coding standards forced him to find a better fix that he'd otherwise have passed over", and that's what I was arguing against.
  • microsoftie (unregistered) in reply to Matty

    If there is a coding guideline, there must be code reviewers.

    Automated code review is useless if you write:

    int user = money;

    The variable names must be indicative of what they are storing. No script can verify that.

    If you can commit to the central repo without a code review, your company is a joke.

  • microsoftie (unregistered)

    On every big lesson of this is:

    1. Only improve speed when the speed is measured AND slow.
    2. Always try first to use hashmaps to improve speed.
    3. Measure the speed afterwards and if it is not 10x better, ditch that solution and find a better one.
  • Superguy (unregistered) in reply to Dogsworth

    Yep, and i'd like to add this to it. A programmers standard shouldn't be judge by how well they follow the the current practices, but by being able to recognize when they need to break; from them.

    As it stands, if the practices are bad, then that should be most of the time.

  • JRI (unregistered) in reply to Matt Westwood

    But if they are fucking stupid, how do so many manage to reproduce?

  • anonymous (unregistered) in reply to JRI
    JRI:
    But if they are fucking stupid, how do so many manage to reproduce?
    By fucking, stupid.
  • Erik (unregistered)

    Here I am thinking my company's lack of guidelines are sloppy and inefficient.... yay! we're efficient in our lack of guidelines :D

  • Anon (unregistered) in reply to Paul Neumann

    A for-each loop in Java looks like:

    for(Item item : list)
    {
      ...
    }
    

    For lists like ArrayLists (like vector in c++), this is compiled at run-time just like the following code:

    for(int i = 0; i < list.size(); ++i)
    {
      Item item = list.get(i);
      ...
    }
    

    In other cases, the iterator approach is used instead:

    Iterator<Item> iterator = list.iterator()
    
    while(iterator.hasNext())
    {
      Item item = iterator.next();
      ...
    }
    

    The for-each loop is clearer, and its use even allows the JVM to optimize the loop type at run-time. Using for-each where appropriate is therefore very good practice. The "no breaks from loops" coding practice having no exceptions is where the blame should be put.

  • dc (unregistered)

    "for loops are more efficient than while loops" That sounds like my Java teacher, who took off points when I used while loops when I could've used for loops. (Wouldn't that be every time? You'd think, but she also didn't have a concept that the middle part of a for loop could by any condition, not just one related to the initialized variable)

Leave a comment on “Coding Practices MUST Be Followed”

Log In or post as a guest

Replying to comment #:

« Return to Article