Meaningful parameters.

[Stanley Sutton]

I can add some comments to that effect.  I'll change material back to m.
I guess the other thing I've done is to try to be consistant about the
names.  For example, in xxx_extract_action, the pointer to the unit
which receives the extracted material I call 'extractor', and when the
id of the unit is needed, I've changed the name to 'extractor_ut' from
'u2' to disginguish the pointer from the unit type. Maybe 'extractor_u'
would be better?

I also changed 'unit3' used in the stack iteration to 'stack_unit',
although 'stacked_unit" might be better.

I'm not changing things that are fairly obvious, such as t for terrain
type, or newt for new terrain type, just mostly things that get
confusing, such as unit2, unit3, t2, t3, etc.

Thee is already some consistancy, unit pointers are almost always
'unit', but unit types are almost always 'u'.


-----Original Message-----

From:	Erik Jessen [mailto:ejessen@adelphia.net]

Sent:	Sat 03-Aug-02 16:56

To:	Stanley Sutton; xconq7@sources.redhat.com

Cc:	

Subject:	Re: Meaningful parameters.


Making code more standardized, readable and maintanable is

*always* worth it.



Are you going to put some sort of a standard someplace in the

comments (so other people can follow it)?



Erik



----- Original Message ----- 

From: "Stanley Sutton" <sutton@t-surf.com>

To: <xconq7@sources.redhat.com>

Sent: Saturday, August 03, 2002 2:20 PM

Subject: Meaningful parameters.





> Since I'm in actions.c, documenting, I'm trying to modify the
parameter

> names to someting a little easier to follow while I'm changing things.

> 

> I'm pretty uniformly changing *unit to *actor, m to material, n to

> amount.  After that, things are a bit less uniform.  It's wordier
(more

> wordy?), but I think it reads a little better.  Of course, it means

> backtracking and changing things I've already documented, and changing
a

> fair amount of code, but it's probably worth the effort.

> 

>