• foxyshadis (unregistered) in reply to Sanhadrin
    Sanhadrin:
    VS:
    This is not a WTF!

    Long time ago, before the while loop existed, this was the available loop with scope.

    for(;;) { // do stuff if (something) break; }

    Er, except, that's not what he's doing. Rather than putting the increment and terminating conditions of a counter in the for statement, he put it in the body, as if he was trying to implement a for loop in a while statement.

    But, obviously you knew something so incredibly basic, and I'm obviously getting trolled. That's the preferable reality here.

    Yo dawg, I heard you like implementing for loops with for loops.

    /captcha "eros". er, thanks, community server, I like you too?

  • (cs) in reply to chubertdev
    That wasn’t a problem until John later tried to add some features to the category listing and expected the array variable to still hold an array.

    Dear John,

    I'm sorry but we just don't have the same values any more.

    Love, Your Array

  • Crash Magnet (unregistered) in reply to shadowman
    shadowman:
    for (;;) {
    

    Ugh. That has to be some kind of amateurish attempt at micro-optimization. That completely missed the mark.

    So, what wrong with it?

  • same Anonymous Coward (unregistered) in reply to foo
    foo:
    chubertdev:
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    Then you have two WTFs.

    Don't say these words! Now someone's gotta make a lame regex pun.
    Our performance DBAs refused to let us devs use Oracle 10g regexp in our SQL because regexp was "too slow," and forced us to write illegible, unmaintainable sub-sub-sub-sub-etc queries that used INSTR and SUBSTR. Code couldn't get built outside the Dev region unless the DBAs signed off.

    My last job would probably make for a pretty decent sidebar (it was at Accenture, natch) if I ever bothered to create a forum account.

  • Bob the destroyer (unregistered) in reply to VS
    VS:
    This is not a WTF!

    Long time ago, before the while loop existed, this was the available loop with scope.

    for(;;) { // do stuff if (something) break; }

    Except what he was trying to do was this:

    for ($i = 0; $i < 15; $i ++ ) {
      // do stuff
    }
    

    Oh, and you, VS, are an idiot. Woosh, TRWTF is you, etc etc etc.

  • (cs) in reply to Anonymous Coward
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    Clearly, in the interests of symmetry, this means that only coders should have write access to the management repository.

  • Sherman (unregistered) in reply to da Doctah
    da Doctah:
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    Clearly, in the interests of symmetry, this means that only coders should have write access to the management repository.
    That, Dr., is one repository I as a software engineer, do not want access to.

  • Norman Diamond (unregistered) in reply to Euripides
    Euripides:
    Reminds me of code my former boss wrote (in PL/SQL):

    for rec in cur loop <<lbl>> if (condition) goto lbl; ... end;

    And then she complained that the database was too slow.

    Role name mismatch exception: Euripides was the one who caused the damage and Eumenides was the one who fixed it.
  • mvaeilrh a (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Crabs:
    ObiWayneKenobi:
    Steve:
    Or, y'know, you could let version control do its job and not leave redundant code all over the place.
    This. There is NO excuse beyond laziness or ignorance for having redundant code like that or, worse, having commented out code blocks "just in case" or // Ticket #42: Fixed frobulation of hobnobs to correctly grouse the hobnob -jsmith type of comments.

    I comment out code all the time. It's usually because I'll want to use parts of it during the rewrite of the function, but I'm not sure what yet. I usually delete it after I'm done. Sometimes I forget.

    Oh fuck off! What's wrong with // Ticket #42: Fixed frobulation of hobnobs to correctly grouse the hobnob -jsmith?
    not sure if you serious or not, but let me tells you this.... when there's a comment outlining what happened and under what change, is a lot easier to immediately recognise WHY something is there, and delve the source control for what other change happened. All these people that say "let the source ocntrol do it's job" may not have worked on projects/support role where things change much. When I stare at a line, and say "whyever they do this?" the source control needs me to check multiple version to find whcih one of them was the one what introduce the change.

    Comments explaqion WHY something is happen. Sometimes a comment like "//change 135" allow you to look up wot change 135 is. The same line but uncommented mean you don't trivially know where it come from or why there. The same line but with big explanation of change 135 is a bit over the moon too....

  • neminem (unregistered) in reply to mvaeilrh a
    mvaeilrh a:
    Comments explaqion WHY something is happen. Sometimes a comment like "//change 135" allow you to look up wot change 135 is. The same line but uncommented mean you don't trivially know where it come from or why there.
    And preempting the response I can see coming, "that's what the Blame tool is for", which totally disregards the fact that Blame only tells you the most *recent* change to a particular line, so if anything else changed after the change you care about, you can no longer tell that way.

    Commented out "just in case" blocks are fine on your local machine, but generally shouldn't end up in svn, I agree. But comments stating why particular code changes were made, with links to any applicable bug reports, absolutely do belong in svn, as they are extremely useful. What could you possibly have against them?

  • Jim (unregistered) in reply to neminem
    neminem:
    Steve:
    Or, y'know, you could let version control do its job and not leave redundant code all over the place.
    Fair enough. I am Adam, it amused me to see something I'd noticed appear here for the first time, and I will mention that, while I did find a copy of this particular small project in our svn, it wasn't the most recent version of the project, compared to one that had been fiddled with by one person, then passed by email to someone else to fiddle with it. And yes, that is definitely what version control is for.

    Another fun fact about the same project: when I got to the project, every time it was called (which was every http request for a particular site), it took a statically-defined array of literal strings, iterated through that static array adding each element to a new List, then did a Contains on that List to see if the page was whitelisted. Why the original coder (who I have honestly no idea who it was; nobody actually in our office, I don't think) didn't just define a static List with the whitelist strings instead, I'm pretty baffled. (I know, iterating through a list of a dozen or so strings creating a new list takes basically 0 time compared to an actual http request, and premature optimization is the devil and stuff, but it was just so bafflingly -ugly-, I had to fix it.)

    Is version control used to provide the ability to be able to revert to old code, or to keep track of what's changed? Or a little bit of column A and a little of column B?

    I think commenting out large chunks and leaving them in is stupid (unless they're part of a bigger change and there's a strong possibility that they'll be used again - although even then not sure). Leaving in comments that outline which change has modified something, on the other hand, is (IMO) good practice. In a project that is either long, or has a high turnover of developer (both of which are common) you want to leave as many clues for those that come after you as you can. On a project where you are the only person making changes it might be possible to remember roughly what changes have been made, but in a project more broadly spread it's likely that you won't realise that Request For Change 89 is the one where you modified line 742 of some_function.c Given that happens to be the most complex of the files and that it is changed in approximately 30-50% of all changes - and that we are now up to RFC 157, you try to identify which change was actually responsible for that. You have several options. You can read through all the RFC justifications/requirments and consider whether they could have hit line 742, or you can look through Source Control (presumably in a binary search type strategy). The former is speculative and long, while the latter is non-trivial (although not overly difficult). A comment like "/* included RFC89 */" tells you where to go looking.

    I think most people here have previously agreed that the most useful comments are the ones that explain obscure or counter-intuitive code and often changes create obscure or counter-intuitive code (because we rarely have the luxury of a full redesign and instead have to make something work with what's already there).....

  • (cs)

    So now "having to check multiple versions" is worse than having garbage code? Wow...

  • Ter (unregistered) in reply to chubertdev
    chubertdev:
    So now "having to check multiple versions" is worse than having garbage code? Wow...
    No, having to check multiple versions is worse than being able to instantly see which version to check. I think there's been a digression from the original (which was bad code because it was a useless if-else that executed the same either way) to the current (which seems to be more an argument about whether changes should be commented or just stuck in version control).
  • (cs) in reply to Ter
    Ter:
    chubertdev:
    So now "having to check multiple versions" is worse than having garbage code? Wow...
    No, having to check multiple versions is worse than being able to instantly see which version to check and having garbage code because of it. I think there's been a digression from the original (which was bad code because it was a useless if-else that executed the same either way) to the current (which seems to be more an argument about whether changes should be commented or just stuck in version control).

    FTFY

    I'm not talking about the comments, I'm talking about the "if X then A else A" code.

  • fred (unregistered)

    To be frank, the 1st two are generic WTFs, you can find them in lots of languages. The last one, though, is a truly classic WTF that PHP has to offer. Do refer to the foreach mechanism for further readings.

  • Matt (unregistered)

    if X then A else A

    will surely mutate into

    if X then A else Almost-A

    so if the intent is to temporarily emasculate the X, comment out the if and the second A. Or delete them.

  • (cs)
    if (dncrptList.Contains(destName)) { dId = SymmetricMethod.Decrypto(id); } else { dId = SymmetricMethod.Decrypto(id); }
    It really is a SymmetricMethod!
  • Josh (unregistered) in reply to portablejim
    portablejim:
    The first snippet would be fixed by using
    while(true)
    instead of
    for(;;)
    and properly closing the input tag.

    And proper escaping of " in the string...

  • (cs)

    I tried it. The first snipped does not "compile" because the double quotes are inside double quotes. So I added backslashes like this:

    $i = 0; for (;;) { $i++; echo "<input type="text" name="row[]">
    "; if ($i >= 15) break; }

    Now it runs, but every input field has exactly the same name; that is, "row[]", so I would not know how to find the values entered in the different input slots.

    Maybe somebody oversimplified his example?

  • (cs) in reply to Ter
    Ter:
    chubertdev:
    So now "having to check multiple versions" is worse than having garbage code? Wow...
    No, having to check multiple versions is worse than being able to instantly see which version to check. I think there's been a digression from the original (which was bad code because it was a useless if-else that executed the same either way) to the current (which seems to be more an argument about whether changes should be commented or just stuck in version control).

    Most source control systems I've used have an annotate (blame/praise etc) function, so you can drill down to that pretty quickly.

    The real problems with "// Issue 255 comments" are:

    1. over time some of the lines to fix Issue 255 get deleted or re-factored, and (worse) some of them get changed without the comment being edited.
    2. If people are good at sticking to the idiom, the code ends up with an issue number on every line (which is not helpful).

    On rare occasions, if a fix ends up needing a WTFish line of code, I've put in "// This is needed for issue 255" in the hope that someone will look up issue 255 for an explanation, but this is definitely the exception, and I only use it if the explanation is too long to fit in a comment.

  • QJo (unregistered)

    Probably already been said (I haven't read through all the comments), but the construct unearthed by Adam happens more often than you'd expect. In this case it was probably a function of a refactoring where the condition has been moved to within the method being invoked. Obviously one of the tasks following that is to find all the places where that code was called and remove the offending if construct. It is easy to make a mistake when doing this. In this particular case, testing will not reveal the mistake made.

    So: no WTF, engineers doing an adequate task, business as usual, move along there, nothing to see.

  • Maurizio (unregistered) in reply to Crabs
    Who doesn't love using Exceptions to govern program flow?

    Actually, non local return are a nice and elegant way to govern program flow in some cases, like non deterministic parsing, and was widely used in some language like Lisp, but also in C.

    It is a pity that in Java an Exception is always an "error signal" bringing with him the heavy weigth stack, but exceptions as flow control is not always bad as believed.

  • a.c. (unregistered) in reply to AndyCanfield

    It's PHP so values entered into inputs will get into a numerical array

  • a.c. (unregistered) in reply to AndyCanfield
    AndyCanfield:
    I tried it. The first snipped does not "compile" because the double quotes are inside double quotes. So I added backslashes like this:

    $i = 0; for (;;) { $i++; echo "<input type="text" name="row[]">
    "; if ($i >= 15) break; }

    Now it runs, but every input field has exactly the same name; that is, "row[]", so I would not know how to find the values entered in the different input slots.

    Maybe somebody oversimplified his example?

    of course my comment above was in reply to that

  • causa (unregistered) in reply to Frank

    (;;) is the emoticon of Cthulhu.

  • (cs) in reply to Roby McAndrew
    Roby McAndrew:
    The real problems with "// Issue 255 comments" are: 1. over time some of the lines to fix Issue 255 get deleted or re-factored, and (worse) some of them get changed without the comment being edited. 2. If people are good at sticking to the idiom, the code ends up with an issue number on every line (which is not helpful).
    Actually, one of the biggest problems is what happens if the bug database gets lost or migrated to another platform that uses a different scheme for issue identifiers. At that point, all those identifiers are useless.

    On other hand, relying on the VCS to hold the information in the history isn't much better. People lose repositories (data corruption, corporate takeover, whatever) and it can be difficult to hunt down just what change happened and when. (It's particularly a problem when there are plenty of merges about, and it's all raised to the WTF! when you're using SVN...)

    Let's face it, there isn't a magic “do your job for you” tool; sometimes you just have to actually figure it out by hand. But if you have to do that from first principles, you've got some code that is too hard to understand and it is time to refactor it or at least leave a (currently correct) comment in so that whoever next deals with it — possibly you, possibly someone else — doesn't need to work so hard.

  • Rob (unregistered)

    The first and the fourth examples look like stupid programmers, but the second and third look more like the result of several generation of modifications to the code, not that it is right, but rather the programmer being told when it is blank, it must do this.

  • (cs) in reply to mvaeilrh a
    mvaeilrh a:
    not sure if you serious or not, but let me tells you this.... when there's a comment outlining what happened and under what change, is a lot easier to immediately recognise WHY something is there, and delve the source control for what other change happened. All these people that say "let the source ocntrol do it's job" may not have worked on projects/support role where things change much. When I stare at a line, and say "whyever they do this?" the source control needs me to check multiple version to find whcih one of them was the one what introduce the change.
    If you don't have an IDE or other system with proper support for the blame function of your version control, it's your own problem. There's really no good reason for manually implementing the blame functionality using comments in code. The blame always returns current results, whereas comments always get out of sync with reality.
  • (cs) in reply to Ter
    Ter:
    chubertdev:
    So now "having to check multiple versions" is worse than having garbage code? Wow...
    No, having to check multiple versions is worse than being able to instantly see which version to check. I think there's been a digression from the original (which was bad code because it was a useless if-else that executed the same either way) to the current (which seems to be more an argument about whether changes should be commented or just stuck in version control).
    Man, your version control must suck, or you plain don't know how to use it, because this was a solved problem even a decade ago. You should be able to point to a line of code and see when it was changed, and who committed the change. Just like that, not having to manually dig up version history or anything of the sort. If you don't know how to do it, there's a high chance you never bothered to RTFM, or you're using some obsolete piece of shit for your VC.
  • (cs) in reply to dkf
    dkf:
    On other hand, relying on the VCS to hold the information in the history isn't much better. People lose repositories (data corruption, corporate takeover, whatever) and it can be difficult to hunt down just what change happened and when. (It's particularly a problem when there are plenty of merges about, and it's all raised to the WTF! when you're using SVN...)
    What you advocate is sheer insanity. Oh, so we can't trust VCS. Maybe we can't trust the hard drives either, so lets just duplicate all files in the repo, just in case something got corrupted. See where that goes? You got a tool, use it. If someone fucks it up, don't worry ahead of time about what costs will there be to be paid when that happens. You'll be horribly unproductive with that kind of a mindset.

    If a VCS gets lost and you have to deal with the consequences, let your higher ups know that someone else's cluelessness has cost them X man hours. Maybe they'll learn from it, maybe not, it's not your problem.

  • instigator (unregistered) in reply to mvaeilrh a
    mvaeilrh a:
    not sure if you serious or not, but let me tells you this.... when there's a comment outlining what happened and under what change, is a lot easier to immediately recognise WHY something is there, and delve the source control for what other change happened. All these people that say "let the source ocntrol do it's job" may not have worked on projects/support role where things change much. When I stare at a line, and say "whyever they do this?" the source control needs me to check multiple version to find whcih one of them was the one what introduce the change.

    Comments explaqion WHY something is happen. Sometimes a comment like "//change 135" allow you to look up wot change 135 is. The same line but uncommented mean you don't trivially know where it come from or why there. The same line but with big explanation of change 135 is a bit over the moon too....

    I'm not going to say that citing bug numbers in code comments is bad, but you might be interested in the "annotate" feature available in most version control systems. It will show you the version number and user that last changed each line of code.

  • instigator (unregistered) in reply to Kuba
    Kuba:
    dkf:
    On other hand, relying on the VCS to hold the information in the history isn't much better. People lose repositories (data corruption, corporate takeover, whatever) and it can be difficult to hunt down just what change happened and when. (It's particularly a problem when there are plenty of merges about, and it's all raised to the WTF! when you're using SVN...)
    What you advocate is sheer insanity. Oh, so we can't trust VCS. Maybe we can't trust the hard drives either, so lets just duplicate all files in the repo, just in case something got corrupted. See where that goes? You got a tool, use it. If someone fucks it up, don't worry ahead of time about what costs will there be to be paid when that happens. You'll be horribly unproductive with that kind of a mindset.

    If a VCS gets lost and you have to deal with the consequences, let your higher ups know that someone else's cluelessness has cost them X man hours. Maybe they'll learn from it, maybe not, it's not your problem.

    Well put. For further information read up on SEP fields: http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem

  • instigator (unregistered) in reply to Kuba
    Kuba:
    If you don't know how to do it, there's a high chance you never bothered to RTFM, or you're using some obsolete piece of shit for your VC.

    Irrational ClearCase?

  • instigator (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    I always ask about version control during a job interview. Not just because version control affects my job satisfaction, but it also says allot about the company. Poor VC choices indicate that management does what they want, without listening to their employees.

    Sensible VC - Nice company to work for. No VC - If its a small software staff, probably Ok. You can host your own, and possibly get company support for it. Management will not micromanage you. Stupid VC with erroneous rules and/or poor tools - Get the hell away from there!!!

  • neminem (unregistered) in reply to instigator
    instigator:
    I'm not going to say that citing bug numbers in code comments is bad, but you might be interested in the "annotate" feature available in most version control systems. It will show you the version number and user that last changed each line of code.
    Except that's exactly what I already said earlier:
    neminem:
    preempting the response I can see coming, "that's what the Blame tool is for", which totally disregards the fact that Blame only tells you the most *recent* change to a particular line, so if anything else changed after the change you care about, you can no longer tell that way.

    Maybe other source control systems are different, but Subversion is pretty much standard from what I've seen, and in Subversion, blame only tells you when it was most recently changed. Which is often good enough, but not always. Sometimes you still end up having to browse the whole list of changes to that file looking for all the instances of the line being changed, to find the change you actually care about, which stinks. (And god forbid if anyone moved the file.) Obviously you don't need to comment every time you make a change to a file; that is what svn, and svn comments are for. But if your change was part of a fix to a bug that was reported by a user, it's pretty convenient to know that when you look at the source later, so you can easily look up the bug report (and, assuming the person responsible for the fix was kind enough to put the bug report number in the svn comment when they checked the fix in, also makes tracking down the commit extremely easy just by searching for that bug report number.)

  • Christopher (unregistered) in reply to neminem
    neminem:
    Sometimes you still end up having to browse the whole list of changes to that file looking for all the instances of the line being changed, to find the change you actually care about, which stinks. (And god forbid if anyone moved the *file*.)
    Every good VCS, even Subversion, tracks a file's history when it is renamed or moved. If somebody manually deleted from the VCS, renamed/moved, and added that file back to the VCS (which is more work than renaming/moving a file through the VCS), you can blame the person who did that, not the VCS.

    I think some VCSs like Git can maintain a file's history when you rename or move it outside the VCS, as long as it's not deleted through the VCS first.

    This all comes back to knowing how to use the tools properly.

  • (cs) in reply to foo
    foo:
    chubertdev:
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    Then you have two WTFs.

    Don't say these words! Now someone's gotta make a lame regex pun.
    I beg to differ. This one stands on its own.

  • (cs) in reply to Drake
    Drake:

    New emoticon? Why not Zoidberg?

    (;;) {

    Reading that in Zoidberg's voice provides extra lulz. Or lolols. Or maybe giggling.

  • justme (unregistered) in reply to Bob
    Bob:
    Abusing the for construct to emulate a while loop is a wtf.
    FTFY
  • (cs)

    Semaj must be dealing with German coworkers who have OCD.

    "But an exceptional condition has occurred, no? Therefore an exception MUST be thrown! Otherwise how will the runtime know that there has been a break in program logic?"

  • TortoiseWrath (unregistered)
    the loop Rasmus found

    I'm trying to decide who just got served by whom.

  • (cs) in reply to Pock Suppet
    Pock Suppet:
    Eve:
    Adam, the most important thing about an if statement is to get the braces on separate lines.
    Heresy! True programmers only use single-line, braceless block constructs. Preferably heavily nested:
    if ( foo )
       while ( vmixingCase_Styles )
          if ( some || any )
          for ( blargh in blargher )
             if ( !blargh )
                thisVar = "1"
                if ( thisVar == "1" )
                   doGoValidate_Blargh( blargh )
    
    This example serves to clearly demonstrate the superiority of braceless block constructs. (To our great regret, the !blargh block was unable to utilize this superior technique appropriately. Perhaps the programmer was unfamiliar with the "if ( thisVar = "1" && thisVar == "1" )" pattern. Alas.) It also demonstrates many excellent ways to irritate your co-workers - 3-space indenting (which is one of my favorites), indented braces, braces indented a different amount than the standard indent, nested code blocks which aren't indented, non-nested code blocks which are indented, "unit testing" your language of choice by assigning variables then testing the assignment, pseudo-Hungarian notation use of "v" prefixes (to indicate "variable"? We also use "z" to prefix form elements :/). Sadly, while I didn't lift the actual example from our code base, it definitely originates there in spirit - each of the styles in that block is well represented in the code I have the pleasure of maintaining every day.

    Re the "if ( thisVar = "1" && thisVar == "1" )" pattern:

    How lame. Anyone knows that the following would be a much more sensible pattern with fewer side-effects: "if ( thisVar = "1", thisVar == "1" )"

  • Norman Diamond (unregistered) in reply to Kuba
    Kuba:
    dkf:
    ...
    What you advocate is sheer insanity. Oh, so we can't trust VCS.
    Is that supposed to be irony? If so, there's a problem for you. It's true.
    Kuba:
    Maybe we can't trust the hard drives either, so lets just duplicate all files in the repo, just in case something got corrupted. See where that goes?
    Like I did last year, recreating part of a repo after a hard drive failed? An actual hard drive failure is rarer than a Microsoft failure but it happens. I had enough backups to recreate the part of the repo that we still needed. Maybe I should have duplicated files in the repo's structure too.
  • Gunslinger (unregistered)

    There should be some way to revoke someone's degree when they write code like these examples. Yes, I'm assuming they got a degree in something.

  • (cs) in reply to AndyCanfield
    AndyCanfield:
    I tried it. The first snipped does not "compile" because the double quotes are inside double quotes. So I added backslashes like this:

    $i = 0; for (;;) { $i++; echo "<input type="text" name="row[]">
    "; if ($i >= 15) break; }

    Now it runs, but every input field has exactly the same name; that is, "row[]", so I would not know how to find the values entered in the different input slots.

    Maybe somebody oversimplified his example?

    No, that is the way it is supposed to work. The browser will submit the 15 values, with the same name, and php will then put them all in the array automatic(because the name end with []).

  • JimTheJam (unregistered) in reply to Eve
    Eve:
    I think your cow orker has learned ...
    I was wondering exactly what a "cow orker" was and so googled "orker", and proceeded to waste a half hour. The most informative site said:

    "Orker er eventyrfigurer, vanligvis framstilt med et mørkegrønt uhyggelig utseende og med store tenner stikkende ut av munnen. Orker er kjent fra både historier, ..."

    Unfortunately, I don't know Norwegian, so that didn't help me much. I did find http://wackypedia.wikia.com/wiki/Cow-orker which informed me, in part:

    "A cow orker is a person who specializes, either professionally or as a hobby, in orking cows."

    The site was most informative: history, warnings (DO NOT try to ork bulls, llamas, or mice), and other tidbits.

    Thanks for a most interesting waste of time.

  • Anonymous Coward (unregistered) in reply to instigator
    instigator:
    Anonymous Coward:
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    I always ask about version control during a job interview. Not just because version control affects my job satisfaction, but it also says allot about the company. Poor VC choices indicate that management does what they want, without listening to their employees.

    Sensible VC - Nice company to work for. No VC - If its a small software staff, probably Ok. You can host your own, and possibly get company support for it. Management will not micromanage you. Stupid VC with erroneous rules and/or poor tools - Get the hell away from there!!!

    My mitigating factors in working there: 1. I was a new college graduate. 2. It was in the middle of the 2007-2008 recession. 3. When I accepted the job, I was a new college graduate unemployed for over a year due to the recession. Yes, I was working on personal projects when not mailing out resumes or working non-tech jobs. 4. Due to 1+2+3, I was living with my parents at the time. I was desperate to move out. 5. It was my first job out of college, so I didn't know better about things like VCS. 6. I didn't know what the project would be like because it was Accenture (Did I mention I was a new college graduate? And that I was desperate?).
  • jay (unregistered) in reply to VS
    VS:
    This is not a WTF!

    Long time ago, before the while loop existed, this was the available loop with scope.

    for(;;) { // do stuff if (something) break; }

    That's right! In all my coding, I'm always careful to not use any language features that didn't exist 50 years ago. If it was good enough for John von Neumann, it's good enough for me!

  • jay (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    ObiWayneKenobi:
    Steve:
    Or, y'know, you could let version control do its job and not leave redundant code all over the place.
    This. There is NO excuse beyond laziness or ignorance for having redundant code like that or, worse, having commented out code blocks "just in case" or // Ticket #42: Fixed frobulation of hobnobs to correctly grouse the hobnob -jsmith type of comments.
    At my last job our rationale for doing this crap was a combination of "we've always done it this way" and "only managers have write access to the code repository."

    I'll let that second point sink in for a bit.

    If your programmers are that incompetent or that malicious, the solution is not to restrict access to the code repository, but to hire some new programmers.

  • jay (unregistered) in reply to JimTheJam
    JimTheJam:
    Eve:
    I think your cow orker has learned ...
    I was wondering exactly what a "cow orker" was and so googled "orker", and proceeded to waste a half hour. The most informative site said:

    "Orker er eventyrfigurer, vanligvis framstilt med et mørkegrønt uhyggelig utseende og med store tenner stikkende ut av munnen. Orker er kjent fra både historier, ..."

    Unfortunately, I don't know Norwegian, so that didn't help me much. I did find http://wackypedia.wikia.com/wiki/Cow-orker which informed me, in part:

    "A cow orker is a person who specializes, either professionally or as a hobby, in orking cows."

    The site was most informative: history, warnings (DO NOT try to ork bulls, llamas, or mice), and other tidbits.

    Thanks for a most interesting waste of time.

    I think your confusion comes because you did not realize that when adding "er" to a word, any termining "c" must be changed to a "k" to prevent the "c" from acquiring a soft ("s") sound under the rule that "c" followed by "e" or "i" is soft.

    Thus, a cow orker is someone who performs genetic manipulations on cows to turn them into orcs. Saruman hired many of these.

Leave a comment on “A Simple Misunderstanding”

Log In or post as a guest

Replying to comment #:

« Return to Article