[Freeciv-Dev] Re: (PR#6174) Loading transports

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=6174 >

I've watched this, and frankly none of the suggestions satisfy many of the
reasons given for choosing them.

I think this means in part the concept is too complex to document in a
trivial name, or is not really clear in the documenter's mind. For instance,
the difference between exist and survive raises more questions than it
supposedly helps resolve, and thus just requires more explanation.

If these are unit functions, then they should start with "unit_"
followed by the method name. Thus in C++ the unit_ is dropped as they
are made part of a class unit.

So with the unit_ prefix, something like

   can_survive_at_tile()
   can_survive_at_tile_fuelled()

   is_valid_tile()
   is_valid_tile_and_fuelled()

are slightly better as they at least don't introduce additional differences
as between exist and survive, but hopefully give the idea of a basic and
extended test that just adds more clauses.


Another way to handle this is with parameters. This might be more extensible
in the long run.

   unit_can_survive_at_tile(<UNDER_CONDITIONS>, ...)

where the conditions are a possibly bitwise ORed { STANDALONE, TRANSPORTED,
FUELLED, ... }

If done right the latter means one never has to add a new function or change
the existing ones if one is just updating conditions, but just update the
enum and add/remove and new/old code that is being updated. It also hekps
keep the name length under control.

Cheers,
RossW
=====

Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=6174 >
> 
>>[per - Fri Feb 27 23:20:16 2004]:
>>
>>On Fri, 27 Feb 2004, Jason Short wrote:
>>
>>>Really? That seems not to be very explanatory, especially since these
>>>are unit functions not tile functions.
>>>
>>>A shorter function name would be nice.But these functions are only
>>>used in a few places so readibility is more important than writability.
>>>If they're absolutely too long I'd suggest
>>>
>>> can_unit_exist_at_tile
>>> can_unit_survive_at_tile
>>>
>>>although even this may lead to confusion (the unit CAN exist, just not
>>>without a transporter...).
>>
>>How about:
>>
>>unit_tile_valid()
>>unit_tile_valid_and_fuel()
> 
> 
> I don't really like them.  They get rid of the is_ prefix that indicates
> the boolean nature.  Also "valid" is an overused term that isn't very
> clear (a "valid" tile is one that the unit can be on without being in a
> transporter?).
> 
> Is your problem just that the original names are too long?  I've long
> had problems with the overly short names that we generally use and
> aren't at all descriptive.  Longer names can lead to less readible code,
> but only if they're used a lot.  These functions aren't.  That said, I
> don't care too much about function naming.  Until an overall design is
> put in place that gives a consistent naming scheme, we should just try
> to do the best we can.
> 
> jason
> 
> 
>