• onitake (unregistered)

    And TRWTF is (as usual) the horribly bloated MS coding style...

  • (cs) in reply to Tim
    Tim:
    This is a bad poke fun at someone who was just doing their job. As a consultant I normally reformat code the first time I am through it just to make myself comfortable with the codebase before I go making large changes. This post seem immature and childish.
    Congratulations for successfully trolling several commentors!
  • (cs)

    Hey, my name is Carl, you insensitive clod!

    And, if I recall my Dilbert correctly, the recovery project should be "TTP" which stands for "The TTP Project." Recurse enough times and you might find "TCPRP" in there somewhere.

  • Techpaul (unregistered) in reply to Medinoc
    Medinoc:
    It does improve the performance of people actually reading the thing, though: Less pointless scrolling, more use[color=red]less[/dolor] text visible at a time...
    There that's fixed it and may have speeded it up as well..
  • abitmol (unregistered) in reply to Mr. Information
    Mr. Information:
    /quote] "Sarcasm aside, I'd really like the OP to confirm: was the formatting the only change in the "optimized" version?"

    No.

    [image]

    We can see in the right bars that the changes displayed are the only ones with whitespace changes. All the other modifications (1 & 2) contain several removal without add counterpart, and possibly few add without a removal counterpart.

    Maybe the consultant is an asshole. Changing indentation without referring to the developpers is not nice and might break automatic checks or editors expectations. But he didn't just do that.

  • anonymous (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    The no-spaces thing wasn't universal across machines. IBM's PC BASIC (also Microsoft's GW-BASIC) had an assortment of reasons why you occasionally needed whitespace
    Steve The Cynic:
    That, however, would work, because TOY *begins* with a token, so the token (TO) is correctly separated from the variable name (Y) that follows it.
    GW-BASIC actually didn't allow spaces there either, because it allowed you to create a variable name that began with a token. For example, 
    CLEAR:RESET:NEW
Ok 
10FORI=1 TO3:?I:NEXTI
LIST
10 FORI=1 TO3:PRINT I:NEXTI
Ok 
RUN
Syntax error in 10 
Ok 
?FORI
 1
Ok 
    (I pressed Esc to clear the line when it re-displayed line 10 for editing after the Syntax error. Pressing Enter would have an implicit CLEAR which would prevent ?FORI from displaying 1.)

    Notice that FORI is a valid variable name, and FORI=1 executed successfully before the syntax error occurred. If you saved that program and opened it in a text or hex editor, you'd see that "FORI", "TO3", and "NEXTI" were not tokenized as "FOR I", "TO 3", or "NEXT I", but were tokenized as if they were variable names.

  • Meep (unregistered) in reply to Oslo
    Oslo:
    JavaScript vet:
    Funny, removing whitespace works wonders for the speed of many Javascript projects/libraries. If that's all you knew, why not start with what you know works in your favorite language.

    I wish I was kidding.

    I wonder if someone has made a minifier for compiled language sourcecode? That would be a real WTF.

    It would make sense if you wanted a compiler agnostic form of precompiled headers.

  • anonymous (unregistered) in reply to abitmol
    abitmol:
    [image]

    We can see in the right bars that the changes displayed are the only ones with whitespace changes. All the other modifications (1 & 2) contain several removal without add counterpart, and possibly few add without a removal counterpart.

    Actually, if you look at the way it parsed the changes, you see that it thinks this:
        set
{
txtCCName.Text = value;
}
}
    was removed without any add counterpart.

    So, I wouldn't feel safe assuming that just because there are removes without add counterparts (or adds without remove counterparts), that the other changes didn't just change the whitespace.

  • OptimizedCoder (unregistered) in reply to Oslo
    Oslo:
    I wonder if someone has made a minifier for compiled language sourcecode? That would be a real WTF.

    They do... it's called a Compiler.

  • Paul Neumann (unregistered) in reply to anonymous
    anonymous:
    Steve The Cynic:
    The no-spaces thing wasn't universal across machines. IBM's PC BASIC (also Microsoft's GW-BASIC) had an assortment of reasons why you occasionally needed whitespace
    Steve The Cynic:
    That, however, would work, because TOY *begins* with a token, so the token (TO) is correctly separated from the variable name (Y) that follows it.
    GW-BASIC actually didn't allow spaces there either, because it allowed you to create a variable name that began with a token. For example, 
    CLEAR:RESET:NEW
Ok 
10FORI=1 TO3:?I:NEXTI
LIST
10 FORI=1 TO3:PRINT I:NEXTI
Ok 
RUN
Syntax error in 10 
Ok 
?FORI
 1
Ok 
    (I pressed Esc to clear the line when it re-displayed line 10 for editing after the Syntax error. Pressing Enter would have an implicit CLEAR which would prevent ?FORI from displaying 1.)

    Notice that FORI is a valid variable name, and FORI=1 executed successfully before the syntax error occurred. If you saved that program and opened it in a text or hex editor, you'd see that "FORI", "TO3", and "NEXTI" were not tokenized as "FOR I", "TO 3", or "NEXT I", but were tokenized as if they were variable names.

    We get it. You made a "four eyes" joke. No need to drag it on.

  • (cs) in reply to Tom

    This

    Tom:
    Calling .ToString() on a string is a WTF by itself...

    Even the SelectedValue property returns a string. I find it funny that the System.String class inherits the ToString() method from System.Object.

  • n_slash_a (unregistered) in reply to codingsmith
    codingsmith:
    voluntold is the best word ever.
    +1
  • William (unregistered)

    Reminds me of a project I was on at a large computer company where we were porting a large Unix project to Windows. The remote Windows team was noticing that their build results were HUGE compared to the builds our team was doing (both on Windows) and they were trying to figure out why.

    The lead engineer at the remote site posited that the difference in the size of the build results was because of Windows systems using CR LF instead of LF in the source.

    <facepalm />
  • Hannes (unregistered) in reply to Tom
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
  • (cs)
    “TCP” had nothing to do with the “Transmission Control Protocol”, but there are only so many TLAs out there.
    FTFY
  • (cs) in reply to Hannes
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))

    Yup, always a bunch of that.

    System.Convert.ToBoolean(Convert.ToInt16(dr["BooleanField"].ToString()))
  • (cs)

    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.

  • OP (unregistered) in reply to Mr. Information

    Yes, that really was the only change committed for the "performance optimization", a whole bunch of files (20+) that had the whitespace consolidated!

  • Publius (unregistered) in reply to Tim
    Tim:
    This is a bad poke fun at someone who was just doing their job. As a consultant I normally reformat code the first time I am through it just to make myself comfortable with the codebase before I go making large changes. This post seem immature and childish.
  • Caffeine (unregistered) in reply to OP
    Article:
    but there are only so many three-letter-acronyms out there

    You'd think with 17576 possibilities there'd be a few that haven't been used yet...

  • (cs) in reply to operagost
    operagost:
    I imagine that's because Javascript is interpreted.
    JavaScript hasn't been truly interpreted for a long time. Modern JS engines all compile the JS source to an intermediate bytecode level. Most are backed by an optimizing compiler that will monitor the bytecode for hot functions that are type stable (i.e. always working on the same variable 'shapes') and will then compile them down to a native code version.

    (They revert back to the unoptimized bytecode when a new 'shape' is encountered though, which means type stability of a parameter or variable has a significant impact on performance.)

    JAPH:
    If you researched the problem, you would find that the JavaScript doesn't run faster just because it's been minimized; Minimized code takes up less bandwidth reducing slowdown for the client to receive it. Once the client has the code, both the minimized and normal code run the same.

    The removal of whitespace speeds up the parsing phase of the code slightly.

    A proper minifier will need to follow the algorithm for automatic semicolon insertion (ASI) and insert missing semicolons or code may break when folded onto a single line. If the minifier pre-applies ASI, it means the JS parser will not run into situations where it has to run those rather expensive checks itself anymore, again saving on a little bit of parse time.

    Ofcourse, both are hardly significant on powerful hardware. They do tend to become noticeable on slower mobile devices processing in the megabytes of JS code for web applications though.

  • Biggles (unregistered)

    Course it's more efficient....it uses less code

  • (cs) in reply to Ragnax
    Ragnax:
    A proper minifier will need to follow the algorithm for automatic semicolon insertion (ASI) and insert missing semicolons or code may break when folded onto a single line. If the minifier pre-applies ASI, it means the JS parser will not run into situations where it has to run those rather expensive checks itself anymore, again saving on a little bit of parse time.

    Reason #2139 that I hate how loose the web is.

  • (cs) in reply to Tim
    Tim:
    This is a bad poke fun at someone who was just doing their job. As a consultant I normally reformat code the first time I am through it just to make myself comfortable with the codebase before I go making large changes. This post seem immature and childish.

    Depends on the context, which we don't definitively get in the story here. If the TCP team is presenting these as real optimization improvements, that's TRWTF. But if Carl is only checking the latest check-in, and he's assuming that it is meant as an optimization, then he's TRWTF.

  • Biggles (unregistered) in reply to codingsmith
    codingsmith:
    voluntold is the best word ever.
    I second that
  • JOe (unregistered) in reply to Tim
    Tim:
    This is a bad poke fun at someone who was just doing their job. As a consultant I normally reformat code the first time I am through it just to make myself comfortable with the codebase before I go making large changes. This post seem immature and childish.
    Thankyou for clarifying why consultants are generally considered bad value for money.
  • Evan (unregistered) in reply to Pawprint
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree with this.

    Though it also makes me sad. Shouldn't our tools make it easier to not have to deal with stuff like that? I mean, it's not hard now with many tools, but you still have to take an explicit "ignore whitespace changes" step, and other tools don't support it. Though I'm not sure what I'd recommend.

    (Actually what I think would be kind of neat but probably wouldn't work is to run every commit through a formatter to change it to a canonical layout, and then on every checkout run it through another formatter to set it to whatever you as the developer likes to see. Sort of like how CRLF conversion works with some version control tools. Though I hate CRLF conversion, so maybe that's not a good idea. :-))

  • (cs) in reply to JOe
    JOe:
    Tim:
    This is a bad poke fun at someone who was just doing their job. As a consultant I normally reformat code the first time I am through it just to make myself comfortable with the codebase before I go making large changes. This post seem immature and childish.
    Thankyou for clarifying why consultants are generally considered bad value for money.

    $250/hr 4 hours of deleting whitespace

    "I did a grand job of optimizing your code!"

  • Yale (unregistered)

    In all fairness, it may not run any more efficiently, but it'll at least compile faster, by virtue of having to read fewer bytes of source code from the disk.

  • (cs) in reply to Evan
    Evan:
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree with this.

    Though it also makes me sad. Shouldn't our tools make it easier to not have to deal with stuff like that? I mean, it's not hard now with many tools, but you still have to take an explicit "ignore whitespace changes" step, and other tools don't support it. Though I'm not sure what I'd recommend.

    (Actually what I think would be kind of neat but probably wouldn't work is to run every commit through a formatter to change it to a canonical layout, and then on every checkout run it through another formatter to set it to whatever you as the developer likes to see. Sort of like how CRLF conversion works with some version control tools. Though I hate CRLF conversion, so maybe that's not a good idea. :-))

    This is a start:

    [image]
  • dfsg (unregistered) in reply to Medinoc
    Medinoc:
    It does improve the performance of people actually reading the thing, though: Less pointless scrolling, more useful text visible at a time...
    Neither necessarily improves performance.

    Sometimes it's easier to read well seperated text than large chunks of prose (ie sometimes whitespace readability - who would've thunk it).

    Scrolling takes very little time, unless you're on a terminal where one scroll > size of page. Most people are adept at scrolling while they read.....

  • tego (unregistered) in reply to Hannes
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
    built in error checking. refuses to return a string if the number ain't real....
  • Juan (unregistered) in reply to Pawprint
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree. In fact I make it a habit everytime I have to make a change, to clean up everything I don't like first; check in; and then check out and make the changes I need to.
  • A S:Idgvuasb zxcbn (unregistered) in reply to Juan
    Juan:
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree. In fact I make it a habit everytime I have to make a change, to clean up everything I don't like first; check in; and then check out and make the changes I need to.
    There are some real wanks on here
  • (cs) in reply to tego
    tego:
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
    built in error checking. refuses to return a string if the number ain't real....
    int check;
if(!int.TryParse(textBox1.Text, check)) {
   // raise validation error
}
  • (cs) in reply to Yale
    Yale:
    In all fairness, it may not run any more efficiently, but it'll at least compile faster, by virtue of having to read fewer bytes of source code from the disk.

    For any optimizing compiler on any modern system, parsing is not a large part of the compile time. One 3,000 line C file takes 0.26 seconds to compile with GCC without optimization, and 1.10 seconds with -O2. So parsing the file is less then a quarter of the time of optimized compilation, probably much less.

  • QJo (unregistered) in reply to A S:Idgvuasb zxcbn
    A S:Idgvuasb zxcbn :
    Juan:
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree. In fact I make it a habit everytime I have to make a change, to clean up everything I don't like first; check in; and then check out and make the changes I need to.
    There are some real wanks on here
    Referring to yourself, I can see.
  • Cheong (unregistered) in reply to codingsmith
    codingsmith:
    voluntold is the best word ever.
    And IMO it deserves to be highlighted.
  • (cs) in reply to chubertdev
    chubertdev:
    tego:
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
    built in error checking. refuses to return a string if the number ain't real....
    int check;
if(!int.TryParse(textBox1.Text, check)) {
   // raise validation error
}

    Unfortunately .Net 1.0/1.1 did not have TryParse, and some people never upgrade (mentally).

  • (cs)

    I'll bet a good number of the Daily WTF readers don't even know what the image is of.

  • iMalc (unregistered)

    I'm guessing they figured that comments would slow it down too. Come to think of it, I'll also keep this comment short so as to not slow the reader down too much.

  • (cs) in reply to Caffeine
    Caffeine:
    Article:
    but there are only so many three-letter-acronyms out there

    You'd think with 17576 possibilities there'd be a few that haven't been used yet...

    Are poo and ass taken?

  • (cs)

    What's the name of that diff-engine? It looks great!

  • Felix (unregistered) in reply to TimGremalm
    TimGremalm:
    What's the name of that diff-engine? It looks great!

    It does (is it windiff?), but isn't TRWTF the posting of a blurry screenshot of a GUI diff tool instead of just a (possibly colorized) plaintext diff?

  • lol (unregistered) in reply to no laughing matter

    oh, you obviously do not work in the IT industry.

    I've seen this kind of crap first-hand, and several times. Its always done by some mumpty who thinks he's somehow better than everyone else, yet is invariably incapable of working with others or providing actual solutions either.

    There again, most of them would simply point to the changelogs and say "but look at all the work I've done, I am amazing, I must be in line for a bonus".

  • Hannes (unregistered) in reply to tego
    tego:
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
    built in error checking. refuses to return a string if the number ain't real....

    True. There still are better ways. For example: Only allow numbers to be inserted in the Textbox? Plus, you really don't need a "ToString" there. The text already IS a string, why on earth would you want to cast a string to a string?

  • (cs) in reply to Hannes
    Hannes:
    tego:
    Hannes:
    Tom:
    Calling .ToString() on a string is a WTF by itself...

    True.

    But, in a program I have to maintain I found the following gem:

      Convert.ToString(Convert.ToInt32(textBox1.Text.ToString()))
    built in error checking. refuses to return a string if the number ain't real....

    True. There still are better ways. For example: Only allow numbers to be inserted in the Textbox? Plus, you really don't need a "ToString" there. The text already IS a string, why on earth would you want to cast a string to a string?

    To really make sure that it's a string!!

    Also, are you going to filter by character, or use a regex. Hopefully not the former, unless you disallow negative numbers, or plan to support "-243-2-34"

  • Jeff Dege (unregistered) in reply to Tim

    As a developer, I have quite strong opinions about the right way to format code.

    But my opinion of people who gratuitously change the formatting of code, is even stronger.

    By committing a change that changes every line of a source file, forever breaks any attempt to merge or diff across that revision. It will make routine maintenance tasks much more difficult, in perpetuity.

    Simply because you couldn't resist your need to impose your own preferences on something that didn't need to be fixed.

  • Barf 4Eva (unregistered)

    really... silly...

    The WTF seems silly too.

    Submit your performance changes separate of your formatting changes.

    Woopdie doo. :|

  • justme (unregistered) in reply to Evan
    Evan:
    Pawprint:
    If you actually MUST change the overall formatting of a code file while also making code changes, the best approach is to check the file out, reformat, and immediately check it back in. This way, version 12 (new formatting) is code-identical to version 11 (old formatting), and then 12 can be compared to 13 to see what the actual code changes were without all the formatting changes showing up as well.
    I agree with this.

    Though it also makes me sad. Shouldn't our tools make it easier to not have to deal with stuff like that? I mean, it's not hard now with many tools, but you still have to take an explicit "ignore whitespace changes" step, and other tools don't support it. Though I'm not sure what I'd recommend.

    (Actually what I think would be kind of neat but probably wouldn't work is to run every commit through a formatter to change it to a canonical layout, and then on every checkout run it through another formatter to set it to whatever you as the developer likes to see. Sort of like how CRLF conversion works with some version control tools. Though I hate CRLF conversion, so maybe that's not a good idea. :-))

    I worked on a project once. I had a computer in the lab and one at my desk ( pre laptop days ). One was windows, one was Unix. I wanted to make quick fix and checked out several files. I never realized the system would do the CRLF conversion and blithely committed.

    Had to explain to change control why every line of code was changed. Sigh. I did the reverse of what was suggested above. Checked out the previous version, checked it back in unedited and then made the changes.

Leave a comment on “The New Line in Performance”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article