• (cs)

    What can one say, besides, "WTF?!"

    These are just so ... wrong!

    I'm reminded of RFC 1927, Suggested Additional MIME Types for Associating Documents.

  • (cs) in reply to Paul Neumann
    Paul Neumann:
    Today's TRWTF is the article hinting towards a useful refactoring pattern: Lookups can be performed more efficiently by table than by while than by for.

    However I'm unclear about the prefer for to while mandate. Clearly, it leads to more critical thinking for cases in which a tree (hashtable in this case) is more appropriate, but there are cases in which a for cannot replace a while such as an application pump. In which language is a for loop not compiled to a while loop?

    in languages where it gets compiled to the visitor pattern (see D's opApply)

  • jaybird (unregistered)

    I think my company has it right, in that coding practices are GUIDELINES, and while it is always strongly recommended that you follow them, you are allowed to break a convention here and there if you can clearly justify WHY you are doing it.

  • (cs) 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.

    Yes... where were these pedants when the original code was checked in?

  • (cs) in reply to Chelloveck
    Chelloveck:
    [...] or how many sheets of TP to use for #1 vs. #2, and whether you should choose one ply or two ply.

    A few years ago I visited Switzerland. In the apartment where I was staying I found not 1-ply, not 2-ply, but... 5-ply toilet paper. I kid you not. 5 separate pieces of paper layered in each square.

    And right then I knew why Switzerland has never been successfully invaded. Forget the military service requirements and the mountains riddled with bunkers. The rest of us just have no chance against any group of people who need 5-PLY TP!

    With Europe being overrun by greenies, it must at least be made of recycled paper. Would still be hell on a septic system; that stuff probably never breaks down.

  • (cs) in reply to paulm
    paulm:
    ztrem:
    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.
    If they've got a rule that says you can't break out of a loop early, then they've probably also got a rule that says methods must only have a single return.

    These sorts of rules only make sense if you have a rigorous policy of deriving looping code mathematically, by specifying invariants, and pre-/post-conditions... and thereby creating provably correct code.

    The point is, that if code abides by such rules, it makes proving theorems about that code much easier, for both humans and computer devices. But if you don't actually do that, and you don't use any theorem proving software, then you've formatted your code into a form that you don't actually need.

    From what I can tell, no-one at this company appeared to actually have a clue, so we can probably assume that no-one there even knows about theorem proving algorithms, derivation of loops with invariants, or any of that shit, but someone did once read (and copy) some coding standards written by someone else who did.

  • nisl (unregistered) in reply to golddog
    golddog:
    1. I believe the term is, "baited breath."
    I believe you are incorrect. Grammar Nazi fail.
  • cyborg (unregistered) in reply to ceiswyn
    ceiswyn:
    golddog:
    1. I believe the term is, "baited breath."

    Only if you've eaten a bunch of worms in the hope that trout will swim into your mouth.

    (Do people never think about what the words they're using actually mean?)

    If people thought about anything properly this sight would not exist.

  • Confused (unregistered) in reply to On a Break
    On a Break:
    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[sic] using break.

    I don't see how a break statement could make it non-obvious how a nested loop (or other similar construct) is going to function. It breaks out of the nearest enclosing loop (do, for, while, switch).

    If someone doesn't notice something like that when manually unrolling a loop, I question whether they should be unrolling the loop in the first place. And the same is true for deletion of a loop. It affects the nearest containing loop, so removing the loop (and its contents) should remove the break. If the break is left behind, it means other contents of the loop may also have been left behind which would also be bad.

    Or maybe I'm just missing something here? Anyone care to explain (and preferably, provide code examples)?

  • RFoxmich (unregistered)

    Missing snarky HTML comments in article See TDWTF coding pratices page 31 section 4 paragraph 15.

  • RFoxmich (unregistered) in reply to boppןob
    boppןob:
    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.

    guess i owe you a coke

    I'm waiting with (a)bated breath.

  • Jeremy (unregistered) in reply to Confused
    Confused:
    On a Break:
    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[sic] using break.

    I don't see how a break statement could make it non-obvious how a nested loop (or other similar construct) is going to function. It breaks out of the nearest enclosing loop (do, for, while, switch).

    If someone doesn't notice something like that when manually unrolling a loop, I question whether they should be unrolling the loop in the first place. And the same is true for deletion of a loop. It affects the nearest containing loop, so removing the loop (and its contents) should remove the break. If the break is left behind, it means other contents of the loop may also have been left behind which would also be bad.

    Or maybe I'm just missing something here? Anyone care to explain (and preferably, provide code examples)?

    The idea is there's little or no thought that has to go into it later on if loops loop based on the conditions set.

    A for loop could pretty much just be skipped. A while loop you know to look for the things that can effect the conditions. Either way they enter on line 10, they exit on line 23, and they did so because of the conditions on line 10. Period.

    Granted you can find situations where it might make some sense to do this. I'm not sure any guidelines (one return per function, etc) should be a "100% no exceptions" thing. However, his wasn't one of them if it could easily be replaced with a while loop, IHMO. (Not to mention the whole thing could be replaced with no loop.) As my professors liked to say, if you're in a situation where something like that can save the day, you've screwed up somewhere else.

  • Yourname (unregistered) in reply to RFoxmich
    RFoxmich:
    Missing snarky HTML comments in article See TDWTF coding pratices page 31 section 4 paragraph 15.
    ^ Featured comment, right here!
  • Matty (unregistered)

    I liked this bit. "Derek decided to take a look at the code."

    I've never worked at a place where someone in Derek's position could look at the code and commit changes to it. Mind you, apart from a Saturday job, I've only worked at one place, but I'd interested to know if this is unusual.

  • anonymous (unregistered) in reply to Confused
    Confused:
    On a Break:
    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[sic] using break.

    I don't see how a break statement could make it non-obvious how a nested loop (or other similar construct) is going to function. It breaks out of the nearest enclosing loop (do, for, while, switch).

    If someone doesn't notice something like that when manually unrolling a loop, I question whether they should be unrolling the loop in the first place. And the same is true for deletion of a loop. It affects the nearest containing loop, so removing the loop (and its contents) should remove the break. If the break is left behind, it means other contents of the loop may also have been left behind which would also be bad.

    Or maybe I'm just missing something here? Anyone care to explain (and preferably, provide code examples)?

    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).

  • Mozzis (unregistered) in reply to golddog

    "Bated" is correct:

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

    it is an archaic short form of "abated"

  • (cs) in reply to nitePhyyre
    nitePhyyre:
    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!
    2+2=4 2x2=4

    Therefore multiplication and addition are the same operation?

    Just because you get the right answer in this one particular case doesn't mean that the guidelines are correct. If they hadn't been able to use a different structure and were stuck with loops, they'd be boned.

    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?

    Oh what utter bollocks.

    2^2 = 4 so shove your addition and your multiplication up your collective arses, you got to use exponentiation, it's better and newer and more street.

  • TopTension (unregistered)

    In C/C++ you could of course do this:

    bool bFound = false; for (i = 0; i < 100 && !bFound; ++ i) { //code

    if(we have a match)
    {
        //do something
        bFound = true;
    }
    else
    {
        //remainder of code
    }
    

    }

    You see at a glance to the for-Statement, what's going on.

    On the other hand, anyone not looking for breaks and continues before unrolling a loop should look for a job better suited to their ablilies.

  • (cs) in reply to operagost
    operagost:
    Chelloveck:
    [...] or how many sheets of TP to use for #1 vs. #2, and whether you should choose one ply or two ply.

    A few years ago I visited Switzerland. In the apartment where I was staying I found not 1-ply, not 2-ply, but... 5-ply toilet paper. I kid you not. 5 separate pieces of paper layered in each square.

    And right then I knew why Switzerland has never been successfully invaded. Forget the military service requirements and the mountains riddled with bunkers. The rest of us just have no chance against any group of people who need 5-PLY TP!

    With Europe being overrun by greenies, it must at least be made of recycled paper. Would still be hell on a septic system; that stuff probably never breaks down.

    Not putting too fine a point on it, from recent experience it turns out they can't design user website journeys for beans.

  • (cs) in reply to ceiswyn
    ceiswyn:
    golddog:
    1. I believe the term is, "baited breath."

    Only if you've eaten a bunch of worms in the hope that trout will swim into your mouth.

    (Do people never think about what the words they're using actually mean?)

    I remember when the joke originated: "Did you hear about the cat that ate the cheese? He waited with baited breath."

    At the time it was funny because everybody knew what "bated breath" was. Everybody in Britain, anyway, because of the passage in what I think was a Famous Five book which went:

    "... and we'll be waiting with bated breath!"

    "What does bated breath mean?" asked (probably) Anne. "Does it mean we have to breathe really fast, or something?"

    "No, you idiot, it means ..." etc.

    So, as I say, all people of a particular generation in a particular milieu will all know this distinction. Everybody else will have seen the joke (written down), not got it, and promulgated the belief that "baited breath" means "the lying-in-wait breath" in order to catch something attracted by the food you've just eaten.

    But that of course is because 99% of the world is fucking stupid.

  • luptatum (unregistered) in reply to Matt Westwood
    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?
  • (cs) in reply to Confused
    Confused:
    On a Break:
    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[sic] using break.

    I don't see how a break statement could make it non-obvious how a nested loop (or other similar construct) is going to function. It breaks out of the nearest enclosing loop (do, for, while, switch).

    If someone doesn't notice something like that when manually unrolling a loop, I question whether they should be unrolling the loop in the first place. And the same is true for deletion of a loop. It affects the nearest containing loop, so removing the loop (and its contents) should remove the break. If the break is left behind, it means other contents of the loop may also have been left behind which would also be bad.

    Or maybe I'm just missing something here? Anyone care to explain (and preferably, provide code examples)?

    Agreed. You don't handicap the code just because there may be idiots working on it in the future.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    ceiswyn:
    golddog:
    1. I believe the term is, "baited breath."

    Only if you've eaten a bunch of worms in the hope that trout will swim into your mouth.

    (Do people never think about what the words they're using actually mean?)

    I remember when the joke originated: "Did you hear about the cat that ate the cheese? He waited with baited breath."

    At the time it was funny because everybody knew what "bated breath" was. Everybody in Britain, anyway, because of the passage in what I think was a Famous Five book which went:

    "... and we'll be waiting with bated breath!"

    "What does bated breath mean?" asked (probably) Anne. "Does it mean we have to breathe really fast, or something?"

    "No, you idiot, it means ..." etc.

    So, as I say, all people of a particular generation in a particular milieu will all know this distinction. Everybody else will have seen the joke (written down), not got it, and promulgated the belief that "baited breath" means "the lying-in-wait breath" in order to catch something attracted by the food you've just eaten.

    But that of course is because 99% of the world is fucking stupid.

    I don't see why you assume people are stupid for applying Occam's razor to a phonetically ambiguous phrase.

  • (cs) in reply to cyborg
    cyborg:
    ceiswyn:
    (Do people never think about what the words they're using actually mean?)
    If people thought about anything properly this cite would not exist.
    FTFY
  • (cs)

    So TRWTF is that even though the coding practices were right in the end, they were unreasonable (cough) at every other point...

  • Friedrice The Great (unregistered) in reply to golddog
    golddog:
    1. I believe the term is, "baited breath."

    "Bated breath," shortened version of "abated breath". "Baited breath" is for catching fish.

  • dguthurts (unregistered)

    Stupidity of the guidelines not withstanding...

    TRWTF is that Derek apparently updated a PRODUCTION system without going through any sort of change control process, and that somebody else (and who was in charge of "guidelines" and should know better) did it also.

    damnum: darned numbers

  • Anonypony (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, 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!).

  • (cs) in reply to dguthurts
    dguthurts:
    Stupidity of the guidelines not withstanding...

    TRWTF is that Derek apparently updated a PRODUCTION system without going through any sort of change control process, and that somebody else (and who was in charge of "guidelines" and should know better) did it also.

    damnum: darned numbers

    Never said that he updated production, he could have been comparing times in a dev/test environment.

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

    But then they'll crash on another planet, supplant the native population, and breed.

  • (cs) in reply to luptatum
    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?

  • (cs) in reply to Friedrice The Great
    Friedrice The Great:
    golddog:
    1. I believe the term is, "baited breath."

    "Bated breath," shortened version of "abated breath". "Baited breath" is for catching fish.

    Also for catching mice. See Matt Westwood's Official Comments, Article 3, Section 2, Line 1.

  • XXI (unregistered) in reply to Matt Westwood
    Matt Westwood:
    2^2 = 4 so shove your addition *and* your multiplication up your collective arses, you got to use exponentiation, it's better and newer and more street.

    Unless you're doing C / C++, in which case 2^2 = 0

  • XXI (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!).

    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...

  • (cs) in reply to XXI
    XXI:
    Matt Westwood:
    2^2 = 4 so shove your addition *and* your multiplication up your collective arses, you got to use exponentiation, it's better and newer and more street.

    Unless you're doing C / C++, in which case 2^2 = 0

    Any non-idiot would implement the "2^2" pseudocode as pow(2, 2).

  • (cs) 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...

    Assuming that working with clueless idiots will end in anything except frustration and bad code is a horrible idea.

    But then again, that's what firing up Word is for...

  • Krunt (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!).

    The problem is that morons exist whether or not you like it. People hire morons. Sometimes people don't know they've hired morons until the moron has been there for 6+ months. If said moron in question is doing development and nobody is checking said moron's code, it can end up getting released.

    Moron then gets fired a few months later, and you get to support his/her code. It's not always about morons enabling morons: sometimes it's about protecting a valuable codebase (and business as a whole) from risky new hires, or (more often than it should be) veteran devs who think they know best.

    In our shop, code has to go through peer review before being released. Sometimes younger devs would do reviews for veterans and point out a problem/inefficiency in their code and get laughed at (or even bullied) until they approved it anyway. Having a good standards document (complete with examples of WHY doing XYZ is a bad idea) that everyone had to adhere to made that process much simpler for everyone - not to mention far more entertaining when some of the old seasoned developers had to fall in line.

    The problem isn't about coding standards. It's about people.

  • XXI (unregistered) in reply to chubertdev
    chubertdev:
    Any non-idiot would implement the "2^2" pseudocode as pow(2, 2).

    Any non-idiot would know that the actual operator represented by a symbol depends on the context, and that assuming there is a "true" one is a silly idea

  • XXI (unregistered) in reply to chubertdev
    chubertdev:
    Assuming that working with clueless idiots will end in anything except frustration and bad code is a horrible idea.

    But then again, that's what firing up Word is for...

    Unless you're the one doing the hiring, or you're working for a very small firm, you will have to work with morons one day or another, whether you like it or not.

    And anyways subtly breaking things doesn't mean it was done by a moron. Big breaks in code happen when many people add conditions and statements and early breaks to an initially small loop that eventually becomes enormous because of all the small contributions, and that becomes un-maintainable even though it's nobody's fault. Good practices serve for that, to keep a certain maintainability standard. I'm not saying they should be enforced mindlessly, but they certainly do have a reason of existing, be it simply to facilitate the understanding of other people's code and to have a uniform-ish codebase

  • Tristan (unregistered) in reply to golddog

    Nope, the article is right, it's bated breath. It's a shortened form of abated, meaning reduced.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    I remember when the joke originated: "Did you hear about the cat that ate the cheese? He waited with baited breath."

    At the time it was funny because everybody knew what "bated breath" was. Everybody in Britain, anyway, because of the passage in what I think was a Famous Five book which went:

    "... and we'll be waiting with bated breath!"

    "What does bated breath mean?" asked (probably) Anne. "Does it mean we have to breathe really fast, or something?"

    "No, you idiot, it means ..." etc.

    So, as I say, all people of a particular generation in a particular milieu will all know this distinction. Everybody else will have seen the joke (written down), not got it, and promulgated the belief that "baited breath" means "the lying-in-wait breath" in order to catch something attracted by the food you've just eaten.

    But that of course is because 99% of the world is fucking stupid.

    Bah, the "Secret Seven" books were much better than the "Famous Five" books.

  • Worf (unregistered) in reply to Confused

    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. If all of a sudden it now takes a minute, people may think it's broken - it ran then aborted somewhere.

    Hope that was sufficiently explained because people will wonder.

    Confused:
    I don't see how a break statement could make it non-obvious how a nested loop (or other similar construct) is going to function. It breaks out of the nearest enclosing loop (do, for, while, switch).

    Well, you can ask AT&T how well that went on Mother's Day in 1990. Where a misplaced "break" statement in the 4ESS switching software caused the entire telephone system to go down.

    (And remember, this was AT&T, home of Bell Labs, C, and UNIX. If anyone should know what a "break" statement does, it's the home of the inventor....).

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

  • opto (unregistered)

    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...

  • dguthurts (unregistered) in reply to chubertdev
    chubertdev:
    dguthurts:
    Stupidity of the guidelines not withstanding...

    TRWTF is that Derek apparently updated a PRODUCTION system without going through any sort of change control process, and that somebody else (and who was in charge of "guidelines" and should know better) did it also.

    damnum: darned numbers

    Never said that he updated production, he could have been comparing times in a dev/test environment.

    You're right. I read too much into "He’d just saved at least an hour for most people,"

  • (cs) in reply to XXI
    XXI:
    chubertdev:
    Assuming that working with clueless idiots will end in anything except frustration and bad code is a horrible idea.

    But then again, that's what firing up Word is for...

    Unless you're the one doing the hiring, or you're working for a very small firm, you will have to work with morons one day or another, whether you like it or not.

    And anyways subtly breaking things doesn't mean it was done by a moron. Big breaks in code happen when many people add conditions and statements and early breaks to an initially small loop that eventually becomes enormous because of all the small contributions, and that becomes un-maintainable even though it's nobody's fault. Good practices serve for that, to keep a certain maintainability standard. I'm not saying they should be enforced mindlessly, but they certainly do have a reason of existing, be it simply to facilitate the understanding of other people's code and to have a uniform-ish codebase

    I worked just outside of morons at my last job. Then they were brought into my group. That's exactly why I don't work there anymore.

    Although I do agree with your second point, I don't go overboard with it. Going strict with pointless coding practices is usually bad, but can be good. Just ask NASA.

  • (cs) in reply to dguthurts
    dguthurts:
    chubertdev:
    dguthurts:
    Stupidity of the guidelines not withstanding...

    TRWTF is that Derek apparently updated a PRODUCTION system without going through any sort of change control process, and that somebody else (and who was in charge of "guidelines" and should know better) did it also.

    damnum: darned numbers

    Never said that he updated production, he could have been comparing times in a dev/test environment.

    You're right. I read too much into "He’d just saved at least an hour for most people,"

    Wow, dang. I guess that their change control process is TRWTF.

    1. change made to code
    2. change committed
    3. change deployed to production
    4. change reviewed
    5. change reverted

    That's BRILLIANT.

  • eggbox (unregistered) in reply to Martin

    True but maybe the people writing the code in the first place followed the letter of the coding standards and didn't know about using a map so they used the loop without the break.

    I think that having more than about 10 coding standards/rules is plenty, everything else comes down to common sense. Then there is peer review which should catch the rest, i.e. obscure code, difficult to follow code etc.

    When I hear someone saying 'you have to code this way because it is quicker' I cringe because 9 times out of 10 it isn't and the other case is never really proved. If performance is an issue then the standard should include performance testing that is peer reviewed.

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

  • Coding Practices MUST Be Followed (unregistered)

    So someone working at a brach has access to the source code? That's a WTF from the very start.

Leave a comment on “Coding Practices MUST Be Followed”

Log In or post as a guest

Replying to comment #415680:

« Return to Article