• Bill C. (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, such as this:
    10 FORI=XTOY:?I:NEXT
    The interpreter allowed (and would recognise as distinct) longer variable names than just two letters/one-letter-one-digit, and the tokeniser had to be smarter about chopping identifiers at the boundaries of tokens. So the line above would be tokenised as if it were:
    10 FOR I = XTOY : PRINT I : NEXT
    And it would fail at runtime with a syntax error.
    10 FORI=X TOY:?I:NEXT
    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
    WTF were they token when they did that, and can I get some?
  • anonymous (unregistered) in reply to Bill C.
    Bill C.:
    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, such as this:
    10 FORI=XTOY:?I:NEXT
    The interpreter allowed (and would recognise as distinct) longer variable names than just two letters/one-letter-one-digit, and the tokeniser had to be smarter about chopping identifiers at the boundaries of tokens. So the line above would be tokenised as if it were:
    10 FOR I = XTOY : PRINT I : NEXT
    And it would fail at runtime with a syntax error.
    10 FORI=X TOY:?I:NEXT
    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
    WTF were they token when they did that, and can I get some?
    Speaking for MS-GWBASIC, the line:
    10 FOR I=X TO Y:?I:NEXT
    (note the extra space which is required for GW-BASIC to tokenize the TO)

    After saving, this is the tokenized line of code (disregarding the few bytes that signal the start and end of the file):

    0A 00 82 20 49 E7 58 20 CC 20 59 3A 91 49 3A 83
\n \0 é  \s I  τ  X  \s ╠  \s Y  :  æ  I  :  â
    

    0A 00 ... line number (000A = 10)
82 ...... FOR
20 ...... space
49 ...... I
E7 ...... =
58 ...... X
20 ...... space
CC ...... TO
20 ...... space
59 ...... Y
3A ...... :
91 ...... PRINT
49 ...... I
3A ...... :
83 ...... NEXT
    or, leaving in only the spaces that are actually in the tokenized version:
    10FOR I=X TO Y:PRINTI:NEXT
    The spaces can actually be removed from the file and it'll load and run successfully in that form (they won't be added back in during the load). In tokenized form, the keywords are all distinct with no need for spaces around them, even though the editor requires spaces to distinguish them in ASCII form (and doesn't remove those spaces when it tokenizes).

  • Quido Theiss (unregistered) in reply to Tom

    Calling .ToString() on a string is a NOP by itself ...

  • DJ Hoffman (unregistered)

    In some languages, like MATLAB, removing whitespace can actually hurt performance.

  • anonymous (unregistered) in reply to DJ Hoffman
    DJ Hoffman:
    In some languages, like MATLAB, removing whitespace can actually hurt performance.
    Huh? Care to explain?
  • Spudd86 (unregistered) in reply to dtech

    Not these days... it'll speed up parsing but that's it, the main gain from minified javascript is that it downloads faster. Mainstream javascript engines these days parse the code and generate bytecode that they then either JIT compile as needed or just interpret if it doesn't seem like the JITing will be a win.

  • Spudd86 (unregistered) in reply to Meep

    Minifying a header that is frequently included isn't really going to speed anything up since it'll be in the OS file cache the next time it's read and I doubt the minification would make a significant difference to the parse time.

  • (cs) in reply to Jeff Dege
    Jeff Dege:
    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.

    I agree. That's why every company should have a style guide that all developers have to follow, regardless of whether they like it or agree with it.

  • OP (unregistered)

    I've just read some of the comments here and a lot of you do not seem to get it. So I'll reiterate in capitals, so you can see - THE CHANGES YOU SEE IN THAT PARTIAL DIFF VIEW ARE THE ONLY CHANGES SUBMITTED FOR THE PERFORMANCE FIX! ITS NOT A FORMATTING CHANGE AND THEN A PERFORMANCE CHANGE MADE EARLIER - IT'S THE ONLY CHANGE - THAT IS THE TRWTF!

  • OP (unregistered) in reply to Felix

    No, the TRWTF isn't a blurry screenshot of a diff tool, that was just to highlight the only changes made throughout the file - did you really need to see an entire files worth of the same changes to see my point? Really? Truely? Maybe IT is a little too hard for you then..

  • Lex Luthor (unregistered) in reply to Gunslnger
    Gunslnger:
    I agree. That's why every company should have a style guide that all developers have to follow, regardless of whether they like it or agree with it.

    If that's the case, then it needs to be disclosed right up front before or during the interview. That way, those of us who know how to program and can read multiple styles of formatting can decide whether or not steer clear of a potential clusterfuck.

    The problem with opinions like yours are that they assume a competent decision maker. An incompetent decision maker destroys any value that a code standard may have. I've had to turn several projects upside down lately because the new "standard" imposed is schizophrenic, willfully ignorant of the pitfalls it invites, and completely unconcerned about quality control. It's worse than so-called "cowboy coding" because it stifles everyone to the level of the lowest common denominator. And if you have some H1Bs on the payroll, that bar can be so low you'd have to dig a tunnel to trip over it.

  • Kasper (unregistered) in reply to lol
    lol:
    as a professional coder I never make changes to the codebase just because I prefer a reformatted style, such selfishness causes untold grief when y6ou come to check the changelogs!
    Additionally it will introduce merge conflicts, which in the worst case could take as long time to resolve as it took to write the code in the first case.

Leave a comment on “The New Line in Performance”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article