Re: Console.WriteLine(s) Is Missing Line Terminator?

Um, nobody uses Hungarian notation on their variables
any more.

At any rate, I'm not going to argue with you, we can
agree to disagree.

And by the way, Francesco Balena is not a strongly VB-oriented
author. His Standards & Practices book provides information on both
VB and C#. He has book on the languages out for both VB and C#.
And he programs primarily in C#.

Robin S.
---------------------------------------
"Gadget" <gadget@xxxxxxxxxx> wrote in message
news:1vl5mjotmlq4r.1c9qkd432v00c.dlg@xxxxxxxxxxxxx
On Mon, 20 Nov 2006 10:51:15 -0800, RobinS wrote:

Let me step in and support Mattias here.

According to Francesco Balena: "The + operator is supported
as a string concatenation operator only for historical
reasons. Using the & operator to concatenate strings
instead of the + operator makes your code more readable
and less ambiguous."

I guess it's historical in that it's always been the standard in every
languages except VB. It's a bit like saying '+' is only used as a string
concatenator in a fraction of languages; fractions like 50/3 and 17/2 :D

I completely agree. When I see this:

myData = firstData + secondData

If I don't know if those are strings or numerics,
I won't know if it's concatenating or adding.

Quite rightly too! MS also recommend using meaningful variable names. Can
you tell me what types those two variables types are?
For example, is
myData = strFirstName & " " & strLastName
any more readable than
myData = strFirstName + " " + strLastName
?
It's the ease with which it encourages lazy programming that puts me off
the '&' concatenator. How many times have you seen 'bodged' code using '&'
to avoid null errors instead of checking for null properly? I've
frequently
seen code such as strX = DB["Name"] & "" because the coder didn't want to
bother checking if the Name was null? Is this really good coding practise,
and to follow up your example, is it 'readable and unambiguous'?

Overall, using '&' vs '+' to document when you are want your variables to
be treated as strings, or as a lazy way to avoid null checking is pretty
poor programming technique, and assuming you code sensibly then your
variables will have meaningful names, and as shown above, the use of '+'
vs
'&' becomes largely irrelevant.

Matius is arguing strongly that '+' should not be used to concatenate
strings, yet the only argument seems to be a single statement from a
strongly VB orientated author, and a rather dubious statement that it
clarifies what you are doing with appallingly named variables :)

I'm never stated that '&' is the spawn of the devil, I simply inferred
that
it is better programming practise to use '+' to enforce explicit casting
of
numbers to strings.

Cheers,
Gadget

And when Microsoft says something is included "for historical
reasons", to me it's like saying "Say Hasta La Vista to
this feature in the next version, baby."

Robin S.
-------------------------------------

"Gadget" <gadget@xxxxxxxxxx> wrote in message
news:4ebi6gkpz0ah$.kvwwrhdycu4t$.dlg@xxxxxxxxxxxxx
On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

Also as a rule of thumb, avoid using '&' to concatenate strings, as it
has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.


It's only in there for VB6 style compatibility,

No it certainly isn't.


Mattias

I'm still fascinated to hear your reasoning, Mattias. Don't let this
thread
die... :)

Cheers,
Gadget


.

Relevant Pages

  • Re: Console.WriteLine(s) Is Missing Line Terminator?
    ... If I don't know if those are strings or numerics, ... It's the ease with which it encourages lazy programming that puts me off ... Matius is arguing strongly that '+' should not be used to concatenate ... reasons", to me it's like saying "Say Hasta La Vista to ...
    (microsoft.public.dotnet.general)
  • Re: passing pointers [C]
    ... >I could malloc some space, concatenate the first two, malloc some more, ... >strings, do that malloc, and return a new string. ... Since you only call realloc, there is no way for old allocations not ...
    (alt.comp.lang.learn.c-cpp)
  • Re: was: Current Uses for Fortran ??
    ... > Strange because no other programming languages do it. ... > numbers and strings. ... I don't like + for concatenate since I believe that concatenate ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • passing pointers [C]
    ... My app has to concatenate strings to build up a bunch of SQL queries ... I could malloc some space, concatenate the first two, malloc some more, ... gradually built up) and realloc-ing it's memory block. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Best practices for efficient FP string building in CL?
    ... CONCATENATE fast: ... (defun smarter-concatenate-strings (strings) ... (defun not-so-clever-concatenate (strings) ...
    (comp.lang.lisp)
Loading