• (nodebb)

    The obvious frist question is "Did they leave at least one of the calls pointing at "Old"? (Depending on what the old/new difference is, it might be anywhere from semi-reasonable to completely stupid to do such a thing.)

  • Hans (unregistered)

    Is there also something similar to fromHtmlToPdfNewer to be found?

  • John Melville (unregistered)

    A minor WTF. I have made many Method2() or MethodA() or even Type2 when I wanted to try a new implementation of something before fully committing to jettisoning the old one. If they had good refactoring, renaming the old method XxxOld might have been an easy and harmless variation on a completely valid technique.

    The WTF here is not doing the thing -- it is leaving it in the codebase when you are done. Either pick one and discard the other, or rename both of them so that the reason for two different options becomes clear.

  • Dennis (unregistered)

    Nooooot really a WTF to me. Okay, maybe naming, but if multiple functions depends on the incorrect/old behaviour, I'll have no problem doing something like this to switch dependents over one at time. Of course, when it isn't used anymore, the old should be gone, and the new should be renamed.

  • xorium (unregistered) in reply to Hans

    fromHtmlToPdfNewer and fromHtmlToPdfNewest and fromHtmlToPdfLatest and fromHtmlToPdfLast and fromHtmlToPdfReallyLast and fromHtmlToPdfLast_130624 ...

  • My Name (unregistered)

    Why do you think this has anything to do version control? Mostly this comes up as an (poor) attempt on backwards compatibility.

  • (nodebb)

    The real WTF is the naming convention. This is how it should go

     public void fromHtmlToPdfFrist(PrintlogEntry printlogEntry, byte[] inBytes, final OutputStream outPDF) throws IOException, ParseException
    	{...}
     public void fromHtmlToPdfSecnod(PrintlogEntry printlogEntry, byte[] inBytes, final OutputStream outPDF) throws IOException, ParseException
    	{...}
     public void fromHtmlToPdfThrid(PrintlogEntry printlogEntry, byte[] inBytes, final OutputStream outPDF) throws IOException, ParseException
    	{...}
     public void fromHtmlToPdfFileNotFound(PrintlogEntry printlogEntry, byte[] inBytes, final OutputStream outPDF) throws IOException, ParseException
    	{...}
    
  • Darren (unregistered)

    As we all know this will just eventually end up with the function name of

    fromHtmlToPdfNewNewNewV2NewestFinalNewV2aNewV3AbsoluteNewFinalFinalFinal01New()
  • (nodebb)

    AnnualReport2025_Final.doc AnnualReport2025_Final(Revised).doc AnnualReport2025_Final(Revised)Final.doc AnnualReport2025_Final(Obsolete).doc AnnualReport2025_UseThisOne_Final.doc . . .

  • Roby McAndrew (unregistered)

    DibleySoft code review meeting: "So, I'm going to create a new function called 'fromHtmlToPdfNew'" "Good Idea" "But what about the existing 'fromHtmlToPdfNew' ?" "Well, we rename that 'fromHtmlToPdfQuiteOld'" "and the existing 'fromHtmlToPdfOld' ?" "We'll can call that ''fromHtmlToPdfOld'"

  • (nodebb) in reply to Dennis

    it is somewhat WTFy because they've renamed the old function, so had to change all the usages of it, which is utterly pointless.

  • Loren Pechtel (unregistered)

    When you need to fix things but can't commit to doing the whole thing at once. Change the old name, see what works or doesn't. And you know what needs future work. Not ideal, but not horrible.

  • Dennis (unregistered) in reply to thosrtanner

    While true, renaming stuff isn't really a problem in a proper IDE, unless it's an exported symbol used outside the project.

    I'd even argue that can be nice to remind others that it's the old version, though a deprecation would have done that too.

  • (nodebb) in reply to Dennis

    judging by the submission, a proper IDE seems unlikely

  • (nodebb)

    They may still have been using source control previously. But even if they were, they weren't using source control.

  • (nodebb)

    Clearly not from a Windows shop. How many Win33 APIs have SomeMethod vs SomeMethodEx ? Not to mention the DirectX or COM interfaces with V2, V3, etc.

    As for not cleaning the older version, I've done that on purpose in the past to show that these 8 was an evolution and prevent a different newer team member from suggesting "hey why don't we do X?", and then you have to tell them we did and it was terrible... Hopefully the linker will remove dead code, right? Right?

  • (nodebb) in reply to Ralf

    Clearly not from a Windows shop. How many Win33 APIs have SomeMethod vs SomeMethodEx ? Not to mention the DirectX or COM interfaces with V2, V3, etc.

    Backwards compatibility is a bitch.

    Those things exist for a different reason, called "preserving backwards compatibility while allowing new functionality". Consider CopyFile and CopyFileEx. If someone had been prescient enough when initially writing CopyFile, we would never have had CopyFileEx because the extra functionality (and function parameters) would have been built in to CopyFile.

    Of course, whoever it was didn't have the power to predict back then what the complete set of extra functionality would be, nor what extra parameters would be required, so later on, someone (else?) wrote a new function, and preserved the old one to preserve binary compatibility for old not-recompiled programs. (Similar to why FreeBSD kept the file descriptor in a C FILE * as short long after int became 32 bit instead of 16 bit on almost all FreeBSD machines. fileno(f) turns out to be a macro, not a function, so programs have actual post-compile references to the internals of FILE *... <<== This caused us problems when one of our binaries started legitimately having file descriptors bigger than SHORT_MAX which broke calls to fdopen. Long story.)

  • (nodebb) in reply to Steve_The_Cynic

    If someone had been prescient enough when initially writing CopyFile, we would never have had CopyFileEx because the extra functionality (and function parameters) would have been built in to CopyFile.

    BRB making all my functions variadic...

  • Neveranull (unregistered)
    Comment held for moderation.
  • Neveranull (unregistered)
    Comment held for moderation.

Leave a comment on “ConVersion Version”

Log In or post as a guest

Replying to comment #682587:

« Return to Article