• jay (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    Gibbon:
    Drake:
    Frank:
    for (;;) {
    I think there's a new emoticon in there somewhere for that sick feeling you get when the fog of code smell lifts to reveal an actual rotting corpse.

    New emoticon? Why not Zoidberg?

    (;;) {

    I actually giggled. Featured comment?

    Real programmers do not giggle.

    Upon reading examples like these, most real programmers sob uncontrollably.

  • jay (unregistered) in reply to Honnza
    Honnza:
    if (dncrptList.Contains(destName))
    {
       dId = SymmetricMethod.Decrypto(id);
    }
    else
    {
       dId = SymmetricMethod.Decrypto(id);
    }
    

    isn't a WTF. It happens when the logic changes frequently. Rather than merge the two branches and then try to remember what the condition was when the logic requests diverging pathways, you simply leave an if statement stub that you can expect later.

    Coding to specification is like walking on water. It's easier when it's frozen.

    The problem with that thinking is that any rational programmer looking at the code is going to say, "Zounds, there's a bug here! Both branches of the IF do exactly the same thing! Now I've got to figure out what it was supposed to do." And then waste a bunch of time figuring out that this was deliberate.

    There may also be a pointless performance loss if the function called by the IF does a non-trivial amount of work. If it does some complex database query, this could be a serious performance killer for no apparent reason.

    If you're worried about forgetting the function that was called in the IF, may I suggest:

    // We used to test dncrptList.Contains(destName)) here, but now both ends of the IF do the same thing so the test is superfluous
    dId = SymmetricMethod.Decrypto(id);
    
  • mark (unregistered) in reply to jay
    jay:
    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!

    That's the beauty of the C preprocessor: You can write #defines to make your C look almost like assembler!

    #define add(r,x)  r=r+x;
    #define sub(r,x)  r=r-x;
    #define jmpeq(r,lbl) if (r==0) goto lbl;
    #define jmpne(r,lbl) if (r!=0) goto lbl;
    

    Etc.

    Now if I can just find a punch card reader that works with Windows 7, I can really bring back the good old days.

  • mark (unregistered) in reply to mvaeilrh a
    mvaeilrh a:
    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....

    Except that if you have a modern source code control system, there should be some sort of function that says "tell me which change last affected this line". Like SVN's "blame" function, which will give you a source listing with each line labeled with the revision number in which it was last changed.

    I think this is far more useful than cluttering up the code with hundeds of comments saying "change 135", "change 142", etc.

  • mark (unregistered) in reply to neminem
    neminem:
    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?

    Whoops, I posted a reply saying "that's what the blame tool is for" before reading this!

    Except ... if a line of code was changed for revision 135, and then it was changed again for revision 136, surely what matters is revison 136 and not revision 135. Usually I do not care why it was changed to something that it no longer is. If it's a problem where I really need to study the history of how it got the way it is -- like someone says that it worked a year ago but it's been changed six times since then -- then neither a single "blame" run nor a single comment "change #135" is going to tell me what I need to know. In either case I'm going to have to go back through logs.

    Indeed, the "change 136" comment could be misleading. Perhaps someone else has changed it since then and not updated the comment. Maybe it's been changed 20 times since then.

    You could, of course, add comments to identify the change number for every code change. But this would (a) result in incredible levels of clutter in the code, a single line could end up having a dozen such comments; and (b) would just reproduce what is already recorded in the repository anyway, and with less accuracy than the repository.

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

    It's possible that I'll lose my car keys. I could modify my car to provide an alternate way to open the doors and start the car without using the keys but which does not compromise security. Or I could just keep a spare set of keys.

    It's possible that you will lose your repository because of hardware failures, etc. You could respond to that by duplicating all of the information that is in your repository in some other format, such as comments in code, or type up "change control" documents. Or you could just make a backup of your repository.

    If the company decides to change it's version control software because of corporate takeover or because a better product has come out or whatever, at the very least you should keep the old repository for at least a couple of years for reference.

  • instigator (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    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?).
    Its OK Anonymous Coward, I forgive you. :)
  • Mike (unregistered) in reply to Honnza

    Yeah looks dumb might fall into YAGNI but sometimes you have a pretty good idea that things should be different given a particular criteria but don't know yet what the boss wants you to do on both branches. So you do the same thing and rough out the logic flow in preparation for the change. I'd probably just through a comment in the code though or a big chunk of whitespace to draw the eye to it.

  • Neil (unregistered) in reply to Martin
    Martin:
    And John found this one, which demonstrates PHP’s “flexibility”: foreach ($category as $category) {

    While this is not a good way to program stuff, it's not one of those strange PHP quirks.

    Python:

    >>> a = [1, 2, 3]
    >>> for a in a: print a
    ...
    1
    2
    3
    >>> a
    3
    
    EcmaScript 6 has a cure:
    js> let a = [1, 2, 3]
    

    js> for (let a of a) print(a); 1 2 3 js> print(a); 1,2,3

    (Of course, most people are stuck on JScript...)

  • The Big Picture Thinker (unregistered)

    The for(;;) is not really a WTF. Unless you consider the entire C++ standard library a WTF. Because that happens all the over the place in functions you use all the time.

    [image]
  • Wesley Kerfoot (unregistered) in reply to The Big Picture Thinker

    That isn't the same thing as the original code. The original code was putting the for loop logic in the body of the for loop instead of using the actual for loop construct. This is using a for loop in a completely different way,

  • Axel (unregistered) in reply to dgvid

    Quote: "(And how much do you love "Venture Brothers" for giving us this use of the word arching?)"

    It's "The Venture Bros.", Bro'.

    And yes, I'm a fan. Or maybe a fanal. No, that didn't sound good at all. But anal fan sounds worse, so there you go.

Leave a comment on “A Simple Misunderstanding”

Log In or post as a guest

Replying to comment #:

« Return to Article