Jon said:
Just because an operator has been abused in one language doesn't mean
it should be abused in others too. You can get used to any number of
things, but bad habits should be broken. << and >> are not "suck" or
"blow" operators - they're bitshifting operators. Their purpose is in
the specification. That's what they should be used for, and all they
should be used for.
placing the emphasis on names to indicate what a statement does has two
problems. There is the obvious that if you dont know english the
meaning will not be apparent. ( yeah, yeah - keep the name simple and
consistent ). Another major problem is the designers of the .net
framework might make confusing choices.
on friday I had to deal with converting strings to and from ebcdic
bytes. I am still new to .net and had not yet worked with the Encoding
and Decoding classes. ( still dont know the difference between an
Encoder and Encoding ). I gave the MSDN documention 15 minutes and
none of the method names made sense to me. Without the examples I
found in google groups ( I think it was a post of Jon Skeets that was
the best example I found ), I would still be at it.
Here is the code that translate a string to ebcdic bytes:
System.Text.Encoding encoding =
System.Text.Encoding.GetEncoding( 37 ) ;
byte[] bytes = encoding.GetBytes( InString ) ;
"GetBytes" makes little sense to me. "TranslateTo" is more intuitive.
But why rely on either. In my c++ class framework masterpiece the code
reads:
EbcdicBytes bytes( 37 ) ; // code page 37
std::string InString ;
bytes = InString ; // replace the contents of bytes with InString
bytes << InString ; // add InString to the contents of bytes
I think this second example is much more readable. That is just my
opinion. What I dont agree with is the C# designers not allowing the
choice between the two styles. I prefer symbols over words.
-Steve