> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>
> Peter Donald wrote:
...
> This is generally known as "literal programming".
And pretty much breaks the DefaultConfigurationBuilder.
-1
Use comments for comments. If it isn't supposed to be given
to the program code for processing, keep it away from it.
That said...
Elements:
+ Rule 1: Use common sense. Taken from the C++ FAQ lite (better
stated):
http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.14
Another thing: don't assume things labeled as "evil" (macros,
arrays, pointers, etc.) are always bad in all situations. One
size does not fit all. Take out a fine-point marker and write
on the inside of your glasses, Software Development Is Decision
Making. In other words, there are very few if any "never..."
and "always..." rules in software - rules that you can apply
without thinking - rules that always work in all situations in
all markets - one-size-fits-all rules.
In plain English, you will have to make decisions, and the
quality of your decisions will effect the business value of your
software. And sometimes you will have to choose between a bunch
of bad options. When that happens, the best you can hope for is
to choose the least bad of the alternatives, the lesser of the
"evils."
http://www.parashift.com/c++-faq-lite/newbie.html#faq-28.6
Some people are so afraid of making a wrong decision that they'll
adopt a one-size-fits-all rule such as "give a name to every
number."
But if you adopt rules like that, you're guaranteed to have made
the wrong decision: those rules cost your company more than they
save. They are bad rules.
The choice is simple: use a flexible rule even though you might make
a wrong decision, or use a one-size-fits-all rule and be guaranteed
to make a wrong decision.
In short: Peter - just do what feels right. This is like the whitespace
style of your code (brace on same or following line?), and we can expend
a metric shitload of time arguing back and forth with very little of
actual value coming out of it.
Just do something and we'll see how well it holds up. That's what we'd
end
up having to do anyway (as we can only hypothesize about what should be
the
one true rule.) Chances are, it won't matter.
And THAT said...
Personally I prefer elements for multiplicity and for long text:
<description>
This is my component. There are many like it,
but this one is mine.
"This is the second paragraph."
</description>
is better than:
<description text="This is my component. There are many like it, but
this one is mine. "This is the second paragraph.""/>
Those with non-word-wrapping mail clients will appreciate why.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
