Fog Creek Software
Discussion Board

Worst Ever: 7350 Line Function, 55 local vars

I am helping my boss fix this horrendous beast of a project and I come acrossed this beaut of a function.

This single function does everything...from opening the db connection, to figuring out the timezone, to formatting a phone number, to fixing your kitchen sink.  It also modifies all sorts of global data, like there's no tommorrow!

Actually, in that regard it may be the best piece of "stream of conscience" style programming that I've ever seen.

It's amazing that it's worked for this long.  (Good timing for me :)

Tuesday, February 03, 2004

And I bet it's called main()

Egor Shipovalov
Tuesday, February 03, 2004

And the best feature I'm sure, you have to scroll twice to the right to see the bottom of the nesting!

Tuesday, February 03, 2004

At least it had *local* variables. And 7350 lines is only what, 120 pages printed out? Hah. Hardly worth complaining about!

Why back in my day, we used BASIC, with one leter and one number for variables, and we liked it just fine...

What's that you say? Time for my medication? If you say so, Nurse...


Mark Bessey
Wednesday, February 04, 2004

Maybe I have a worse case: one C program, one C file, 488Kb, 13977 lines of code.  No .h file.

The whole file has about three comments. One is a warning: "Please treat the following array very carefully, as it is very delicate".

I'm supposed to migrate it to Java. I'm for sure going to add this to my resumé...

Dario Vasconcelos
Wednesday, February 04, 2004

...and your hospital chart.  (Sorry, couldn't resist.)

Sam Livingston-Gray
Wednesday, February 04, 2004

Heh.  Reminds me of an interview I had with a local ad agency.  Their web "programmer" needed some help with an ASP-based application he'd written.  To his credit, he did seem to have organized his functions (in that he used more than one), but I lost any interest in the job when I noticed that none of them had parameters.

I asked: turns out parameters were messy, and just got in the way.  "It's much simpler to just set everything that needs to be set and *then* just call the function..."

Sam Livingston-Gray
Wednesday, February 04, 2004

Lucky for you, you are working with a refactoring-able IDE. You are, aren't you?.... *snicker*

Tal Rotbart
Wednesday, February 04, 2004

Sam Livingston-Gray, how old is this guy? Man someone wack him upside the head with any one of the 5,000 object oriented or object based programming style guides out there.

Li-fan Chen
Wednesday, February 04, 2004

I know someone who had to port a COBOL accounting program to some other language (the details have been lost in the mists of time), and every single variable, function, etc, was named after a type of fish.

I'm just surprised it wasn't written in C...

Wednesday, February 04, 2004

>> every single variable, function, etc, was named after a type of fish.

I will never stop laughing about this. How many types of fish are there, anyway?

The original post reminded me of a 'graphical editor' I did in Turbo Pascal back in high school. The whole program was a gigantic "while" loop, with some outrageous nesting.

When I added new "features" and it wouldn't compile, I just skipped to the end, and kept adding/removing "end;" statements until it would.

That's because I heard somewhere that function calling had "parameter passing overhead".
Wednesday, February 04, 2004

Accomodate a stranger, would you guys?

What is "stream of conscience"? I suppose it's a cultural reference, but Google didn't help.
Wednesday, February 04, 2004

> The whole program was a gigantic "while" loop, with some outrageous nesting.

Of course, if it had been the other guy, it would have been a WHALE loop

Harvey Pengwyn
Wednesday, February 04, 2004

Someone I used to work with tells me that when he moved to his new job, he found that they had an entire website implemented as a 404 error page. All the links went nowhere, and the code to handle each page was instead of the 404 page.

Sum Dum Gai
Wednesday, February 04, 2004

Hmm... That 404 page kludge isn't too bad an idea. It gives one centralised despatch point off to other pages (perhaps if you wanted to do some odd user rights checking).
I can certainly see why it might have been a good idea, but perhaps not when they sobered up the next morning.

It's one of those hacks that's so ugly it's almost elegant. (kinda like duffs device)

I will be adding this to my list of horrid hacks that I might use one day (It will have to be a very BAD day)

Peter Ibbotson
Wednesday, February 04, 2004

Best. Thread. Ever. =)

Wednesday, February 04, 2004

I started my new job two months ago, and this comment really hit home:

"I asked: turns out parameters were messy, and just got in the way.  'It's much simpler to just set everything that needs to be set and *then* just call the function...'"

It's a big perl program, and everything (and I mean everything) is stored in a huge nested hash called $xml.  He passes it into and out of all his functions.  Which of course expect certain values to be filled out, and inside the functions, the values in this great big $xml are manipulated.  Drives me absolutely insane.

I asked: turns out he likes to be "unconventional" and in fact, he really likes how it turned out.  I wonder why he quit?

We're talking about a total of 26,000 lines of code here, and I'm the sole developer here.  The money is good but damn I have to do -something- about it!

Wednesday, February 04, 2004

The issue there, is whether to refactor it or to rewrite it from the specs.

Wednesday, February 04, 2004

Stream of Consciousness?

See last chapter:

Wednesday, February 04, 2004

How about my current project where I'm "baby-sitting" some code where the state of the current UI is abstracted into a single C++ class.

The class encapsulates 93 references to MFC controls.

It has one constructor. Yup...that constructor takes 93 parameters!  The constructor decalaration is 33 lines long.

The parameters are named
CButton& buta, CButton& butb, CButton& butc, CStatic& sta...etc...

The encapsulated references are called things like
CButton& m_ButtonUp, CButton& m_ButtonDown...etc
There is not even any form of correlation between the names of the constructor parameters and the encapsulated references!!!

It gets better still...the same class is used on 3 different projects that share _portions_ of a each others interfaces (just think "Venn diagram").

The result is there are 3 sets of #defines.
There are also nested #ifdefs in the body of the class declaration, any yes there are nested #defines in the contructor declaration!  If you add a new control to an interface, you _may_ have to add it 1, 2 or 3 times to the constructor paramater list. Get it wrong and you get all kinds of compiler mismatch errors from upto 3 different projects.

I takes about 2 hours to add a single control to any of the 3 user interfaces!  I haven't yet got it right first time.

Yeah right...Get Me Fired
Wednesday, February 04, 2004

>Of course, if it had been the other guy, it would have been a WHALE loop

Since when was a whale a fish?

Wednesday, February 04, 2004

Okay, my turn...

At my previous job, my boss had written the primary application, many years before in C. 10 source files names B1XX.c, B2XX.c ... B10XX. c all compiled into BXX.exe.  Each file was about 10000 lines. Functionality was distributed among files apparently randomly. No one ever new what BXX meant.

When it came to variable the first one was "a", the next was "aa" and so on until about "aaaaaa", the he moved to "b".
And they were mostly global.

Needless to say it was nearly impossible to work on without breaking something.

Wednesday, February 04, 2004

I'd like to thank everyone on this thread who is maintaining any of my old code.

name withheld out of cowardice
Wednesday, February 04, 2004

Li-Fan Chen:  that's the sad thing -- he was about my age (I'm 29)!

What I saw of his code actually looked relatively clean: proper indenting, reasonable variable names, helpful comments, and so on.  He was just hung up on this idea that using globals was "cleaner."  It was like talking to someone who went through their entire day (got on the train, went to work, picked up some groceries on the way home, maybe went out to a movie after dinner) with his underwear on the outside of his pants -- because otherwise they might get soiled, you know -- and honestly believed everyone else should do it that way too.

(Of course, this was ASP, which may be the ugliest multi-language mess I've ever seen.  But to me, that makes it that much more important to write good code...)

Sam Livingston-Gray
Wednesday, February 04, 2004

Astrobe: Rewrite from specs? What specs?

A few years ago I was given some legacy code (actually, this project is still nominally my responsibility; meh). No specifications or documentation of any kind, so my first task was to figure out how on earth the program worked. There was this one header file - #included just about everywhere - that contained the immortal lines:

#define width 9

(It turned out to be the size in bits of a certain field, and could only be changed if you updated various other things as well. A curse on whoever figured this out, changed the value, and then left the original comment as it was.)

Still, I was slightly heartened that the original programmer had pulled the "magic number" out of his code into a #define. Indeed, this principle had been followed elsewhere in the program. Later, I found:

char magic_number[] = { ... };
char magic_number2[] = { ... };
char magic_number3[] = { ... };

The program itself isn't that large, but it does generate a lot of output. This is done by a series of functions that each produce a "subreport". These subreports are stuck in an array. Then another function comes along, allocates a huge chunk of memory, and concatenates each subreport into that space. The report text is by now Quite Large, so... we make another copy -- the idea is that one copy can be displayed on the screen, and the other written to a file. (The original array is also still hanging around.) A comment says that we need to make copies "so that it will be fresh".

Wednesday, February 04, 2004

"Since when was a whale a fish?"

I have it on good authority that whalers used to call whales "fish"...

Grumpy Old-Timer
Wednesday, February 04, 2004

I used to work with someone who didn't believe in naming subroutines or functions with words, as this required unnecessary compromises i.e. the name would inevitably not capture the subtleties. Therefore everything was given a number, according to some taxonomy e.g.
X8081, XX999, IX8811 etc.

Harvey Pengwyn
Wednesday, February 04, 2004

Then  again, someone else I worked with had heard it was A Bad Thing to use numbers in the code, therefore he defined

or whatever the FORTRAN syntax is, I forget.

He was very proud of this for some reason.

He was the same person who started comments in column 79 when we used an editor that showed you the first 78 columns unless you scrolled (BRIEF).

Harvey Pengwyn
Wednesday, February 04, 2004

I worked with a C program that had so many nested if/while/for's that after extending out to column 100 or so, he arbitrarily de-indented back about 80 columns and kept on going.  When he again reached about 100 he un-indented again!  One function was over 2000 lines of this crap.

It was a compiler for a processing control language.  The author was proud of his lack of source code comments.

Bathmophobic skier
Wednesday, February 04, 2004

At least with

#define MAGIC_X_NUMBER 20
#define MAGIC_Y_NUMBER 12
#define MAGIC_Z_NUMBER 20

you know that #1 and #3 are different...  I remember spending hours trying to describe them well enough to write documenting comments.

This was the boss who wrote the following struct:
struct crun{
void* next;
int x;
int y;
int c1;
int c2;
Worse yet, it was only used in incredibly complex mathematical operations.  As in, the equations were five or six 80-character lines long, despite the fact that the variables involved had a max of two letters in them.  I never did figure out what c1 and c2 were.

Worst *file* ever, though, would have to go to the H1B visa holder I was working with in 2000, who complained about an IDE bug with scrolling, and wanted me to check it out.  Yup, when a plaintext file reaches a certain number of megabytes it just takes too damn long to buffer, thus creating lagged scrolling.  I don't remember how much "too many megabytes" was, but it was more than one.  In a single code file.  So given my information, she solved it by breaking up the file.  Into stuff_a.cpp, stuff_b.cpp, stuff_c.cpp, etc., with no particular relation of contents.

Wednesday, February 04, 2004

Where to begin...

~100K lines of Perl
95% of all variables are global
indentation is completely random
some developers like to have as many lines of code on one line as possible
the few comments that do exist generally indicate where the end of a block is
variable names are generally 2 characters
subroutine names are generally 3 characters
a majority of the code looks like it was written by students in an intro to computing class (just keep adding code until it works, don't actually understand why it works)
database is denormalized in all the wrong places
some tables have multiple unique keys and different parts of the program use one or the other or both
lead developer is in charge of most design decisions and new features and hates users (is only in this position because he has been with the company the longest, has no business designing software)

I could go on for pages.  We write software that is used by hospitals.  It often doesn't work properly.  Fortunately (for my employer) once a hospital selects our system it is very hard for them to switch to another system (these decisions often take months or years and there are a lot of issues with moving from one system to another).

Wednesday, February 04, 2004

I did embedded stuff for a while (robotics). Once the shop had a homebrew kernel who's API basically consisted of 1 C function "doit" with about 32 int parameters.
The semantics of the parameters changed contextually, depending on the values of other parameters. There was no documentation, no comments.
When I asked how I was supposed to wrtite code on top of this it was explained that to me that you had to go talk to the kernel developer and that he would answer to "specific" questions only.

Just me (Sir to you)
Wednesday, February 04, 2004

Worst I've seen: an O(2) problem implemented as O(8).  Worst yet, the logic to make it into an O(8) was so twisted that it took me several hours to decode into the fairly straightforward O(2) problem that is really was.

Worst I've done: In my first OOP programming class, I had a constructor that was 5 pages long.  The instructor says NO, NO, NO, you need to break up the functionality.  So I did.  I changed the constructor to call a function that was 5 pages long!

too embarassed to tell
Wednesday, February 04, 2004

I think you mean O(n^2) and O(n^8)?

Wednesday, February 04, 2004

Please, Miss! Please, Miss! Pick me! Pick me!

Back in the late 1980s, I was debugging a trade entry program written in Nixdorf Business Basic and running on a Nixdorf 8870 minicomputer.

In that dialect of Basic, you could write a Goto that jumped X number of lines, where X was any positive or negative integer that you wanted. Worse, you could use a variable rather than a constant. So you could have a line of code that said:

Goto MagicNumber

where MagicNumber could contain any integer, and the interpreter would then jump that many lines forwards or backwards. The whole program was littered with these Gotos, and every line of code that you added or removed would change the target of every Goto within range.

After more than a week of trying to debug this program, I quit the company...


Mark Pearce
Wednesday, February 04, 2004

>>I think you mean O(n^2) and O(n^8)?

Yes. It's morning here and haven't had my coffee yet.

too embarassed to tell
Wednesday, February 04, 2004

Mark, I think you win.

Sam Livingston-Gray
Wednesday, February 04, 2004

We have a mad russian in our organization.  Thankfully he works in his own little world but sometimes the rest of the poor soles have to enter into his code and find a bug.  We program in 'C' and he likes to use #defines.  He uses them for a lot of things.  Like, redefining well defined types in the rest of the system, global variables, variables in global structures.  It is really disheartening trying to find a bug when most of the code is actually hidden from you.  I.E.  What does this variable equal to?...  MSDev can't evaluate because it's a #define/macro so we have to hunt down what it actually equals.  It was by shear luck that I managed to actually find the bug location in his complicated piece of code.  A proud moment but no way I was going to share that with the rest of the team.  I'm not going to advertise that I'm good at poking around in his stuff.  They'll come to me later then.

It gives me shivers when I see a large function composed of mainly all capital letters.

This is one of the main gripes we have with his code.  We make a CAD like product and so we have a bunch of cad functions.  He was incharge of a few...  He made on entry point to handle 12, some similar but about 6 unique, cad functions.  And they don't all behave the same.  So of course when we need to change something down low we hit a road block at this 12 in 1 function as it doesn't follow at all and sane logic. 

Some may say at least they are in functions but in his case this isn't helping any.  Really!

Wednesday, February 04, 2004

Are you guys joking, or are these really reflective of what programming in the real world looks like? I'm still in school, and this is one of the most disheartening threads I've ever read on any forum. How do you manage to survive working under such (backwards) standards?

Wednesday, February 04, 2004

Unfortunately the stories in this thread are not only common, they seem to be the norm.  I'd say maybe one in ten software developers is competent.

Wednesday, February 04, 2004

blackmesa, don't kid yourself -- your code is crap, too.  (=

Seriously, there's a lot of existing code out there, and Sturgeon's Law applies.  Most of it gets the job done, sort of, at least well enough that the author's manager decided it worked and they could assign the author to something else.  These are some of the pathological cases.

You survive by changing a little piece at a time, same as every human being (with some exceptions at the top .00001% of the scale) has ever done.  Gradually it gets better, and by developing a strong dislike for others' "worst practices," you discover all kinds of mistakes you'll never have to make.

Sam Livingston-Gray
Wednesday, February 04, 2004


Wednesday, February 04, 2004

saberworks: "It's a big perl program, and everything (and I mean everything) is stored in a huge nested hash called $xml"

I bet this person put "XML" on his resume to get the new job!

Wednesday, February 04, 2004

I don't know, I still feel slightly warped by what I'm reading here. I obviously have my flaws, but a 7350 lines function? A constructor with 33 parameters?

What do you professionals attribute these incoherencies to? Could it be that those who wrote such code were poorly taught how to program? Or is it really the constraints of work?

I feel for you guys. :=(

Wednesday, February 04, 2004

>...named after fish

I once dug through old assembly code where many of the function names were named after Jimi Hendrix songs..."jmp red_house", etc.

Chris Kessel
Wednesday, February 04, 2004


Unfortunately most people are not software developers because they love developing software.  For many people it's simply about the money.

There seems to be a certain mindset that is needed to develop software properly.  Some people just don't have it and simply hack at things until they seem to work.  They never spot patterns and are unable to think about the big picture.

The problem arises over and over again where a person decides they want to "get into computers" because of the money and they decide to major in CS.  Sometimes these people get discouraged because of all the math and don't understand why they aren't being taught VB so they go to DeVry.  Usually these people do no programming work outside of class assignments.  These people then join the workforce and burden the rest of us.  Often these people will be hired by other morons thus allowing them to remain employed for a length of time.  They then have the experience on paper to move to other unsuspecting companies.

Wednesday, February 04, 2004

Me too, me too...
Ok, number 1. They announce a layoff will happen after the managment changes. One week later one engineer is escorted out of the building. Everyone agrees this is the right choice, as long as he does not come back with a gun (a little out side of normal). I am told to find the code for the one project he ever finished.
I can not open the file with any editor I have. It is too large, and there is only on file. I find an 1.5 inch thick printout in his desk. It is one function, start at the top and your done at the bottom.  Told my boss if he ever asked me to change it I quit. Quit for different reasons soon after.
Number 2. We are consutling with a company because their senior engineer is a screw up, but can not be fired. We refuse to use the old 8051 tools, and tell them we are using new better tools. The senior guy must have these new tools for evaluation!
Reports to the CEO and any who will listen the tools suck, they will not compile his application. Why? The error message was "if-else nested more than 256 levels deep."
I $#!t you not!

Doug Withau
Wednesday, February 04, 2004

>> so ugly it's almost elegant. (kinda like duffs device)

Duff's device is the one case where a couple of "goto's" would have been better than all that structured nonsense.
Wednesday, February 04, 2004

If anyone reads this far: I was hired to help with a huge VB project, the largest class file was 1474k and 30k lines!

A total of 400+ classes, modules not counted. They called it a business layer, but didn't more than call the datalayer and copy data into an identical 'business' structure before it was passed back to the gui.

All logic was in the gui. They got it all backwards, as the gui was written in C++, while the business/data layer was written in VB.

To their defence: this monster was concieved by consultants from the dot com era...

Thomas Eyde
Wednesday, February 04, 2004

"We program in 'C' and he likes to use #defines."

Tell me about it! I can't decide which is worse, that stupid #define style of C metaprogramming, or template style of C++ metaprogramming. They'd be better of writing their own language. Oh wait, that's just what they did.

The next time I see:

#define BEGIN {
#define END }

... I swear I'm going to kill someone.

Dennis Atkins
Wednesday, February 04, 2004

This is a truly excellent essay on writing unmaintainable code

Some gems from that essay:

"Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of $0204FB. The color looks identical to pure blue on the screen, and a maintenance programmer would have to work out 0204FB (or use some graphic tool) to know what it looks like. Only someone intimately familiar with Monty Python and the Holy Grail would know that Lancelot's favorite color was blue. If a maintenance programmer can't quote entire Monty Python movies from memory, he or she has no business being a programmer."

"Choose variable names with irrelevant emotional connotation. e.g.:
    marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about."

"Use very long variable names or class names that differ from each other by only one character, or only in upper/lower case. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc. l is an exceptionally fine choice for a variable name since it will, to the casual glance, masquerade as the constant 1. In many fonts rn looks like an m. So how about a variable swirnrner. Create variable names that differ from each other only in case e.g. HashTable and Hashtable."


Mark Pearce
Wednesday, February 04, 2004

And more:

"Compile the code to an executable. If it works, then just make one or two small little changes in the source each module. But don't bother recompiling these. You can do that later when you have more time, and when there's time for debugging. When the hapless maintenance programmer years later makes a change and the code no longer works, she will erroneously assume it must be something she recently changed. You will send her off on a wild goose chase that will keep her busy for weeks."


Mark Pearce
Wednesday, February 04, 2004

    int d;
    d = c;

Yee-hah! I just love semi-colons...

Mark Pearce
Wednesday, February 04, 2004

>>...named after fish
>...named after Hendrix songs

Before I became a CS major, I knew a guy who couldn't complete a basic CS assignment because...he'd named all the variables after characters from Snow White.  Doc = (Dopey - Happy)/Sleepy;  Yeah, he was Dopey all right.

In the end, though, I think the joke's on me.  Ran into him at a reunion and he'd switched to the business department and become a *software sales/marketing consultant*.  Gah.  If you want nightmare stories about industry, blackmesa, it doesn't get much better than that.

Thursday, February 05, 2004

If we are talking code snippets...  The following bug should have been fixable in about 1 minute.  With the Mad Russian's style of code this took much longer.  First I had to find the bug and then fix it. 

Anyway, a GUI toggle item was behaving backwards.  Ok, no problem, should be simple.  Everywhere else the function call to set the toggle is say: dialogItemOn(...) or dialogitemOff(...).  So I hunt in his code for these names.  Couldn't find it.  Which means I have to step through his code to the spot where this happens.  Did I mention that he codes in quite a different fashion than everyone else and trying to find the exact place where the setting of the dialog item was a chore on it's own.  I actually stepped over the problem code quite a few times as it was not what I was looking for.  His code sort of.

  ((MyFlagValue == TRUE) ? EnableItem : DisableItem)(ItemPointer, Yada);

Now, this is the first time I've ever seen the (()?:) construct used this way and I didn't even think it was even legal but apparently it is.  He is choosing between EnableItem and DisableItem, which in his infinite wisdom are #defines for dialogItemOn and dialogItemOff respectively, and both function have the same parameters. 

The #defining was what made finding the bug difficult.  If you're looking for one thing you won't find it if it's something else.  For normal bug hunting that statement may apply in a different way but something like this shouldn't be done. 

When I actually realized this I had to look at the line for a while in awe.  He complains of typing too much but in this case it saved about 1 keystroke from the function name that is used everwhere else.  Plus it would have been so much clearer if he had just used a normal if{}else{} construct.  When you are tired, you don't want to deal with cleverness.  You want to get it done.

Anyway, just another example of the bizarre stuff I sometimes have to deal with.

Thursday, February 05, 2004

Wow. Just... wow.

Thursday, February 05, 2004

In his defense, he is one seriously smart bugger.  He works on a very difficult engine and the engine blazingly fast.  But the engine isn't that easy to interface with, just about as easy as it is to get along with him in person (thankfully he works in another timezone.)  We tolerate him and thankfully the PTB's have pretty well decided to leave him in his engines and not anywhere else.  I.E. he has his little sandbox all to himself while the rest of us play on the beach.

Everyones happy...  sortof.

Thursday, February 05, 2004

one of my favorites was the simple:

if (condition) {
#include "somelargefile.c"
else {
#include "otherlargefile.c"

It was quite an elegant way to completely divorce the definition of the variables from their use (in the included files) while taking a function that would have been a couple thousand lines and making it appear compact.

Devil's Advocate
Thursday, February 05, 2004

Yeah Zekaric that is pretty awesome. I mean, even though it's absolute madness, I would enjoy finding such a bizarre puzzle.

Dennis Atkins
Thursday, February 05, 2004

((MyFlagValue == TRUE) ? EnableItem : DisableItem)(ItemPointer, Yada);

Truly brilliant. Almost everybody is scared to death of the ternary operator already and this just drives the stake right through their hearts.

I can hardly wait to use it in some code.... ;-)

Andy in Austin
Friday, February 06, 2004

Rok on Andy! We think alike. I'm already refactoring several functions to use the inline ternary dispatch table method.

Dennis Atkins
Friday, February 06, 2004

I didn't think it would compile, but it did!
It beats Duff's device :)
Friday, February 06, 2004

It may compile, but it won't necessarily run correctly. BOOLs should never be tested for equality. They can be "true" (non-zero) without equaling TRUE (usually 1).

But then this thread isn't about how to write code correctly...

Friday, February 06, 2004

I always enjoy doing completely pointless and twisted things...

$dum=diddy(); $dum=diddy()+diddy()+$dum-$dum;
$you=$can+talk(); $you=$can+talk() -

But I would NEVER EVER EVER do this in production code.

Caliban Tiresias Darklock
Monday, February 09, 2004

Hmm...I've never written bad code like that before.  The only exception being BASICA with GOTOs, but even the code that I still have from those days is surprisingly well-organized.  Functions in C really helped organize things even more and I got the power of pointers - void pointers.  I've also adapted the concepts like modular code to my constantly growing 500,000 line code-base.

I guess the only weird thing I do is use variable names like 'x', 'y', 'z', 'x2', 'y2', 'z2', etc. for loops and temporary intra-function storage (that is, it goes out of scope a couple lines later).  The distance from declaration to usage is usually only a couple lines or less.  Otherwise, variable names are really long like ColorResolution or FileMapOverrideStruct.  I don't mind typing that since I enjoy typing and know that it will be descriptive enough for the next person to understand.  The downside is that I don't always comment everything that I should.

Thursday, June 10, 2004

*  Recent Topics

*  Fog Creek Home