It's not what it does that's the WTF...
pcount = pcount + 1actid = allprc(1,rowcounter2)actprcid = allprc(2,rowcounter2)imtltyp = trim(allprc(3,rowcounter2))iphysfm = allprc(4,rowcounter2)iwsttyp = allprc(5,rowcounter2)ivol = allprc(6,rowcounter2)ivolunit = allprc(7,rowcounter2)fmtltyp = trim(allprc(8,rowcounter2))fphysfm = allprc(9,rowcounter2)fwsttyp = allprc(10,rowcounter2)fvol = allprc(11,rowcounter2)fvolunit = allprc(12,rowcounter2)It makes [i]perfect[/i] sense! Diving into this app is like diving into the shallow end of the pool.
Short variable names take up less memory, right?
[quote user="zip"]Short variable names take up less memory, right?[/quote]
Now I miss programming basic on my C64 ... ah, the fun I had
What's funny is the most used variable in the code snippet, rowcounter2, is much longer than the rest. Not just rowcounter, mind you - rowcounter2.
real prgmzrs dn't use unncsry vwels.
This isn't even that bad compared to what I've had to clean up. Imagine grabbing over 2 dozen variables from data input, all with values v1, v2, ... vXX. Oh, and did I mention the code that grabbed the data was in an f-ing #define, just to add that extra dose of confusion and obfuscation.
Good times, good times :P
This isn't even that bad compared to what I've had to clean up
Oh, trust me... I've got more up my sleeve muhahahah...
I remember writing (actually, reproducing a mainframe version from memory) a text-StartTrek game on an early PC (XT/AT-class) - the whole thing had to compile into a .com file in 64K - had to do some real optimization to get in those last few subroutines. Of course, the length of the variable names had nothing to do with it, but still...
Obviously they should use boxes, then put those boxes in more boxes.
Is it Friday yet?