While putting in unneeded or joking things would not pass
muster in a
rigorous process such as the witness described,
there is still a lot of
creative style affecting
the outcome of this rational
process.
For instance if a method takes as arguments a string and
a
mode of interpretation, 3 equally good prototype designs
are possible, and
which to choose is purely a matter of
style and taste:
- RetType
Foo(String, Purpose)
- RetType Foo(Purpose, String)
- RetType
Foo(StringAndPurposeClass)
As another example, there is a style
issue of how to name
multiple methods (not the individual names, but their
selection and collection):
- foo, bar and baz
- Foo, Bar and
Baz
- ExpletitiveNotAllowedOnGroklaw, BeyondAllRepair and
BeyondAllZapping (OK, this one would fail the short if
frequently used
test)
- Pregnant, Broke and Undead
And then there is the
leave in or leave out design
issues, like if we provide a method to return a
range of
elements from an Array collection, should we also provide an
API to
return the first N elements. It would be logically
redundant, but might have a
more efficient implementation in
some API implementations, thus justifying its
inclusion.
[ Reply to This | Parent | # ]
|
