Re: Types, packages & objects : the good old naming conventions question (without religious ware)

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Hibou57 (Yannick Duchêne) wrote:
>>
>> An example trap (to me at least) : what about a type which would seems
>> obviously named Size and a parameter which seems obviously named
>> Size ? X would surely not be OK, neither Item.
>
> If Size is the best name for the parameter, and assuming this a
> numeric value, then I'd call the type Size_Value.

Why not follow the typical convention, and call the type Size_Type?
The type name occurs in fewer places, so it's less noise to modify the
type.

>> An idea may be to get a more or less close synonymous (like Count...
>> not very good) for the parameter for which one may naturally be
>> tempted to name Size. But this seems (and is) a work-around, and if
>> the word “ work-around ” really legitimately applies on that
>> situation, this means there is a trouble (not natural, at least). Why
>> the work around will probably applied on the parameter ? Because the
>> parameter comes later when the type definition is already introduced
>> (in the worst case, it may be tempting to change the type name). This
>> latter detail makes us to come to another aspect of the trouble :
>> choosing a practicable type name, may requires an amount of prediction
>> over what instance names may be.
>
> I think that you shouldn't be writing anything until you've decided on
> the type and its operations, including their parameters.

That's not possible, even in principle. You need use cases in order to
design a good type and operations.

-- 
-- Stephe