• CButtius (unregistered) in reply to Haynes
    Haynes:
    What's the picture of the bashed-up Saxo got to do with anything?

    I wouldn't let anyone fix my car K&R-style. The hinges wouldn't match up...

    There's an online "investment" bank around called Saxo...

  • CButtius (unregistered) in reply to ollo
    ollo:
    In fact, char[] is aequivalent to char*. Each one is a pointer to an 'array' of chars, thus a pointer to the first byte of a number of bytes representing a string. The two different representations are only syntactic sugar.

    AFAIR at least. :)

    That is true when passed as a function parameter, so

    int main( int argc, char ** argv )

    is the same as

    int main( int argc, char * argv[] )

    They are not the same in local use where char * points to an external writable pointer while char [] holds the data in the stack, with the length specified, or the length necessary to hold what it is initialised to.

  • CButtius (unregistered) in reply to Buddy
    Buddy:
    Dascandy:
    What's the WTF?

    The cardinal rule among S/W developers: If it ain't broke, don't fix it. Lots wasn't broke, and he fucked with it. This is most definitely a WTF.

    I hope I never work with you and I wouldn't want you to work for my company if I were hiring.

  • Wyrd (unregistered) in reply to Anonymous
    Anonymous:
    I think the little code sample was somewhat irrelevant really, the WTF is perfectly obvious: he changed every single code file in the system just to satisfy his own pedantic vision of "good code". Coders like this are a serious burden to any IT shop, partly because they waste so much time "fixing" other people's code. They also tend to introduce a lot of bugs because of it ("it doesn't need a full test cycle, it's functionally equivalent to the old code"). The worst thing is, this coder is inevitably borne of good coding skills. He has a decent knowledge of the relevant principles and because of this he thinks that his way of doing things is obviously the right way.

    I can live without a solid process assuming the team is small enough and experienced enough but I always mandate a basic level of coding standards for this very reason. Then, when we hire the likes of Winston we just drop the coding standards in their lap and inform them that from now on, all their code looks like the standards. They hate it but it's contractually enforced so they just have to live with it or leave. Of course, I write the coding standards so maybe I'm the Winston after all...?

    You're Winston except that you got special permission to do that because you had the patience and social skills necessary to get to that position. 'Cause after all, we're all squishy humans.

    -- Furry cows moo and decompress.

  • wbkang (unregistered) in reply to joelkatz
    joelkatz:
    relaxing:
    Uninitialized variables are bad, mmmkay?
    Sure, but only because they might be *used* before they're initialized. However, changing: int x; to int x=0; doesn't fix anything. If 'x' is used before it's set to the *correct* value, arbitrarily setting it to zero won't help very much, unless you luck out and zero happens to be the correct value in every case where it was previously used without being initialized.

    And there's no way you can know that without checking each case. So if you have a large project with lots of possible usage of uninitialized variables, you can't just add initialization everywhere willy-nilly and claim you fixed the uninitialized variables problem.

    Well, Java compiler prohibits this and often times this prevents sloppy programming using if-else if-unexpected kind of errors.

  • iMalc (unregistered)

    The article has a very very poor example of what can increase executable size. It's true that initialising an array in the declaration can increase the size dramatically, but chances are that there were only a handful of arrays that were big enough for this to have made the impact it did. For the most part, changes like those made, are a good thing.

    After upgrading compilers once my exe grew in size by a factor of about 15. There was one large array that was initialised upon assignment, and changing that dropped the size right back down again.

    The real problem here is of course: If it aint broke, don't fix it!

  • enimous (unregistered) in reply to basseq
    The WTF is that the programmer partially rewrote a giant legacy application because he didn't like the coding conventions.

    Well, I personally think the WTF are the "coding conventions", but then I fail to understand why having fixed this poorly written code is a WTF?

  • Steve Urkel (unregistered) in reply to maisnon

    Where in the article does it say that the memory leak hadn't been fixed?

    Maybe the real WTF wasn't the "carnage", but as this possibly sarcastic remark points out: "Clearly, this meant that the process was broken and that maybe, just maybe it was time to bring in some change controls and QA oversight?"

    ...followed by: "Nah! The development manager realized the real problem was Winston and that he needed to be fired."

  • Gates Is Antichrist (unregistered)

    I would need a time machine to read more than the one-third of the comments that I did, so sorry if already said: MY TAKE ON WHY 2 CDS:

    The company's distribution method is "incremental" or "differential" to existing customers (think of backup terminology). I.e. changed executables comprise the release. This app presumably has multiple executables, ergo bloato.

    Am I the only one to think of this? I'm a Winstonian C and ASM zealot, yet I feel like I just dumb-jocked this one.

  • Fred (unregistered)

    The original story ptobably said "two floppys". It's just been rewritten into the 21st century.

    By the way, you are all assuming a compiler that puts stack-based variables into the stack. For non-recursive functions, that's not required, and optimising compilers will put stack variables into memory or registers.

    Oh, and the real WTF is using C, where stack allocation rules are not self evident by design.

  • (cs) in reply to OutlawProgrammer
    OutlawProgrammer:
    Good thing we had Visual Source Safe *groan*

    I don't think I've ever heard anyone say that.

  • Pup (unregistered)

    It depends how the compiler handles things I suppose.

    I've worked with a less-than-perfect compiler for the sega megadrive that, if you initialised variables at the point of defining them (int x = 123;) it put them in read only ROM data rather than in working RAM. Not a problem, unless the ROM is, as you'd expect, read-only.

    If the compiler this company used had a similar quirk, and they produced, for example, firmware or other software with data that shouldn't be self-modified, I can see that it would cause a problem.

    Still, that doesn't explain where disc 2 comes from.

Leave a comment on “Mister Fix-it”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article