• VGR (unregistered) in reply to Xepol

    > Actually folks, as a life long Pascal coder, I can EASILY explain this abortion.

    The WTF is not the volume of global variables, nor their names.

    The WTF is "Everything should be clear."

    This weird tunnel-vision continues to this day.  Every programmer thinks his own ball of mud* should be perfectly clear.  Thus the endless stream of material for this site.

    Make your own code as sloppy as you want, but to expect someone else to intuit what variables like "zFstr" do is unconscionable.  Why didn't the original programmer document it when he learned someone else was trying to maintain it?  Because even the original author can barely keep track of it, and commenting it now would be a Herculean effort.

    • If you don't understand the Ball of Mud reference, read this when you have time:  http://www.laputan.org/mud/

  • Jsmith (unregistered) in reply to Andy O.
    Anonymous:

    I began coding in Basic and later in Assembler on a C64 ...


    lda #$57
    jsr $ffd2
    lda #$54
    jsr $ffd2
    lda #$46
    jsr $ffd2

  • (cs)

    I think I remember drwaing pictures on the back of a tractor feed print of this when I was in grade school.

  • Andy O. (unregistered) in reply to seebs

    Well, at a second glance it doesn't seem too bad. But at a third it will get worse (when the real code starts). By the way: attfac means attenuation factor and prbzn_slice whould be clear as well: probabilityzone-slice. And there are lots of new variables within procedures, shadowing global ones, and so on :-o

  • (cs)

    Heh please let me see the implemenation!!! [:D]

  • Chefren (unregistered) in reply to rogthefrog

    Of course the real WTF here is that he used magic numbers.

    This:

    mtx5cod              : array[0..7] of string;

    Should properly be rewritten as

    <font size="2">const SEVEN: int = 7;</font>

    <font size="2">

    mtx5cod              : array[0..SEVEN] of string;
    -------------

    <font size="3">Ah yes and then we can later just change the const value
    </font><font size="2">
    <font size="2">const SEVEN: int = 8;

    brilliant! :)
    </font></font>
    </font>

  • Andy (unregistered) in reply to FORTRAN slinger

    Pleeease, pleease take that away  from mee! [:'(] [:'(]

  • mongoose (unregistered) in reply to Koen

    Wait, is this one of those funny pictures that i have to squint for ?!?

    For this code, I think I need a good martini or three to see the art in it.

    --


  • (cs)

    This is a true work of art, I understand the code but do not understand the code,

    I comprehend but not.... C would make it look better, Pascal syntax is not very...

    nice, if not idiotic which adds to the horror before us. I find coding in assembly

    more clear!

  • (cs) in reply to Jsmith

    Anonymous:
    Anonymous:

    I began coding in Basic and later in Assembler on a C64 ...


    lda #$57
    jsr $ffd2
    lda #$54
    jsr $ffd2
    lda #$46
    jsr $ffd2

    weird ... 6502 assembly code, posted by "jsmith", and it wasn't me... scary to think I have a twin out there!

    ($FFD2 was CHROUT I believe)

  • matt (unregistered)

    looks like asm !

  • Terra (unregistered) in reply to sinistral

    you're hired

  • (cs)

    This is Open-Source is now requirement for most projects, you have to find a new way to obfuscate your code.

  • (cs) in reply to trollable

    *typo (and i can't fix it) Please read:
    Since Open-Source is now a requirement for most projects, you have to find a new way to obfuscate your code.

  • buckminster futt (unregistered)

    I don't understand what the problem is.

    Like all "real programmers"(see below), the brillant author of this software agrees with Ed Post that if the code was tough to write, them the code should also be tough to read.

    And documentation is for simps who can't read the raw object code...

    best regards,

    buck

    __________________________________________________________________

    "Real Programmers Don't Use Pascal"  [ A letter to the editor of Datamation, volume 29 number 7, July 1983. by Ed Post, Tektronix, Wilsonville OR USA.]

  • (cs)

    This code isn't *too* bad... although he should've put spaces after the commas in the first part of the var block.

    It looks like the code was originally simple and had a few vars, but it just gradually got larger and larger...

    Obviously someone who knows the purpose of the code would have a better chance of understanding what those names mean.

  • BPFH (unregistered) in reply to mrsticks1982
    mrsticks1982:
    {attenuation bezogen}

    ahh, this makes it all clear now ?!?!

    maybe if they named their variables as follows it would have been better

    blah1
    blah2
    ...
    blah2000000


    Actually, no, it wouldn't.

    I once had to maintain data conversion code written in VBA on top of MS Access, where they'd given the fields names like "Field1", "Field2", etc.

    I finally gave up trying to figure out exactly what "Field1" (etc.) were used for (and they re-used the fields, so "Field1" in sub A wasn't necessarily the same quantity as "Field1" in sub B) and rewrote the conversion code completely in C++.  Oddly enough, a lot of the problems we'd been having with it went away at that point.
  • John (unregistered) in reply to Mike J

    If G G Allin (with an 'I') had written it, the comment should have changed from 'Everything Should Be Clear' to 'Bite It, You Scum!' ...or perhaps 'Raw, Brutal, Rough & Bloody'... To which I might have responded (after  reading the code) 'Take Aim & Fire' or perhaps 'Watch Me Kill'...

    J

  • Kerin (unregistered)

    oh god.

    at this point i'd say it would almost be easier to blackbox/redevelop the application than piece through that horror. the arms of code (for it is too boxy to be called anything resembling tendrils) reach out of my monitor to club me, even as I reel back in a sensation of nearly lovecraftian horror.

Leave a comment on “Don't Worry, Everything Should Be Clear”

Log In or post as a guest

Replying to comment #51286:

« Return to Article