![Jon Skeet [C# MVP]](./core/images/default/default_avatar_large.png "Jon Skeet [C# MVP]"){kind=avatar}
Re: Search for multiple things in a string
tshad <tscheiderich@f tsolutions.com> wrote:[color=blue][color=green][color=darkred]
> >> When I talk about a Programming Language - I am talking about a
> >> Procedural
> >> Language (C, Fortran, VB, Pascal, etc.).[/color]
> >
> > So you wouldn't regard LISP as a programming language, just because
> > it's functional rather than procedural?[/color]
>
> I don't know much about LISP, but Mathematics is also a language, but not
> the same way as English and German are.[/color]
Indeed.
[color=blue][color=green]
> > Of course, you didn't even specify "programmin g language" before.[/color]
>
> True.
>
> But I did specify, that it depends on how you define it.[/color]
True.
[color=blue][color=green]
> > Right. Immediately the IndexOf value is more readable, by more clearly
> > separating the three separate strings which are being searched on.
> > (Oliver Sturm's version is more readable than that[/color]
>
> I assume you mean "if (Regex.IsMatch( myString, @"something[123]"))".[/color]
No, I mean:
Yes, where the string itself is separated onto three lines.
[color=blue]
> But actually they are both Olivers.
>
> I don't agree there. I think the Regex is just as readable, as long as you
> have a bit of Regular Expression understanding, obviously. I also think
> that if you understand C and didn't understand Regex - you would get what it
> is saying (IsMatch is pretty much of a giveaway). Much than if you didn't
> understand C and so the IndexOf - which doesn't really telling you what it
> is doing.[/color]
Yes it does, it's finding the index of one string within another.
[color=blue]
> IsMatch is much more understandable term than IndexOf.[/color]
The name is as understandable, but the exact semantics are *much* more
obscure. The name doesn't suggest that you can't just put a only in
there and expect it to only match a dot for instance, does it?
[color=blue][color=green][color=darkred]
> >> Again, why do I need a compelling reason. If I have the solution and it
> >> happens to be Regex, I would use it, I wouldn't necessarily say to
> >> myself -
> >> "Is there perhaps a more readable way to write this? I wonder if Jim
> >> will
> >> be able to read this or not."[/color]
> >
> > Then I'm afraid that's your problem. It sounds like you're basically
> > admitting that you're not that interested in readability. Personally, I
> > like writing code which is elegant but easy to maintain. Having *a*
> > solution which happens to work isn't enough when there are obviously
> > others available which could well be simpler.[/color]
>
> I never said that.[/color]
You said that when you have a solution, you won't consider whether a
more readable way of writing it. To me, that demonstrates that you
don't care very much about readability.
[color=blue]
> I never said readability is not an issue, but I am not going to write "Cat
> in the Hat" instead of a novel so that the programmers with the simplest of
> experience can read it. But I am not going to write cryptic code either so
> they can't read it.[/color]
If the "Cat in the Hat" does the job as well as the novel and is easier
to read, why on earth would you want to write the novel?
[color=blue]
> I assume there are company standards to program by and I would follow that.[/color]
There aren't usually company standards down to the level of when to use
regular expressions.
[color=blue][color=green]
> >Having *a*
> > solution which happens to work isn't enough when there are obviously
> > others available which could well be simpler.[/color]
>
> I am not writing simple code, I am writing code to handle a problem. I
> prefer to write good code not simple code. Sometimes they are synonymous,
> sometimes they aren't.[/color]
I disagree - simple code that works (as well as the more complicated
code) is always good. Note that this is in terms of implementation, not
design - there's sometimes a very simple but inelegant design which
ends up costing a lot more work in the long run. That's a different
matter.
[color=blue]
> But in our case, I still them as equally readable.[/color]
You still haven't said whether you see them as equally readable *and
maintainable* to others though.
[color=blue][color=green]
> > Far more time is spent maintaining code than writing it in the first
> > place. Taking the attitude you take above just isn't cost-effective in
> > the long run.[/color]
>
> Don't agree there.[/color]
With which bit? If you're going to disagree with the first sentence
quoted, we really don't have much basis for discussion. I thought it
was pretty much universally accepted these days that code almost always
spends more time in maintenance than in original coding. That's why I'm
always happy to spend a bit more time refactoring working code to make
it easier to maintain.
[color=blue][color=green][color=darkred]
> >> No pushing. No more than your pushing not using it.[/color]
> >
> > But I'll readily admit to pushing the (IMO simpler) solution, for this
> > particular situation. So are you actually admitting that you *are*
> > pushing the use of regular expressions here?
> >[/color]
> In your opinion (as you say).
>
> And you obviously are not listening. I am not pushing either side. I have
> been saying over and over that in this situation, they are the same (IMO).[/color]
But that *is* pushing regular expressions from my point of view, where
they shouldn't be an option.
Consider an exaggerated equivalent situation. Suppose we were
discussing how to implement addition. Suppose I thought that just using
the expression x+y was the easiest way of doing things, and you thought
it was just as easy to write a remote web service which took two
integers. By *not* ruling out the more complex solution, you're
*effectively* pushing it - at least pushing it as an equally valid
option.
[color=blue]
> I am not pushing Regex nor am I ruling them out. You however, can't make up
> your mind. One minute you say that something as simple as the example we
> are using is too complex for a programmer and then proceed to say that you
> would use Regex in other situations (which would have to be more
> complicated), makes no sense.[/color]
<sigh> I don't know whether you're intentionally missing the point or
whether I'm genuinely not getting through.
There is always risk associated with changing code. When writing code,
you should try to reduce the risk that future changes will incur. That
means making the code as simple as possible, and easy to change.
In some cases a regular expression will be a lot simpler to read and
change than the equivalent "primitive string manipulation" code. Those
cases would usually be where the string manipulation involves several
steps, often nested loops etc. There, the complexity of regular
expressions (which is still there) is less than the complexity of the
primitive solution.
In this case, however, the primitive solution is very simple and
understandable. Changing it to search for a different string or an
extra string (or even a string passed in as a parameter) is trivial.
Changing the regular expression is not.
[color=blue][color=green]
> > So again, the code could be made more readable even by just modifying
> > the existing regex replacement, let alone by replacing the regular
> > expressions with simple String.Replace calls. Had they been
> > String.Replace calls, the meaning of the second line would have been
> > unambiguous - you'd have had to write it the simple way to start with.
> >[/color]
> I am not saying there may not be other ways to write the code. As I said, I
> often rewrite my own code later as I see a way I like better that I may not
> have thought of at the time I wrote it. Many times it isn't better code,
> just different.[/color]
In this case though, it *would* be better - it would be simpler to
understand, and simpler to write in the first place.
For instance, I wouldn't have had to consider whether the brackets were
doing something clever or not. I had to look up .NET regular
expressions just to check the meaning in this case. Do you really
believe that a solution which *doesn't* involve that extra thought
isn't better?
[color=blue][color=green]
> > Note that your first replacement will replace two tabs with a single
> > space, but leave one tab alone, by the way. It would be better to
> > replace "\s+" with the space, IMO.[/color]
>
> Probably true. I am not a Regex expert. That was what I came up with at
> the time.[/color]
And that's part of the risk - that someone doesn't put enough effort
into the regex to get the *actually* desired behaviour. Where the
alternative is a complex solution, it makes a lot of sense to put
significant effort into getting the regex right. When you could do the
same thing with a few string operations, it's just not worth it.
(For this first line, a regex is probably the best way to go - but you
need to think about it more closely.)
[color=blue][color=green]
> > I have had to look it up if you hadn't been answering the question
> > though. Why make the code harder to understand in the first place? If
> > you want to replace a space with " or ", just use
> > keywords = keywords.Replac e (" ", " or ");
> > Much more straightforward .
> >[/color]
> Even in C, which I have used for years, I have to look up parameters to make
> sure I have the right parameters and have them in the right order.[/color]
Usually intellisense can help you with that though - it *doesn't* start
explaining the details of regular expressions though.
[color=blue]
> As I said, the Parens were probably a mistake and may have made some changes
> to the line and left the parens in. I agree yours is the correct one.[/color]
And if you weren't taking "use regular expressions" as your default
position, you wouldn't have made the mistake in the first place. The
first thing you should try to think of is the simplest one. You want to
manipulate a string, so ask yourself if there's anything in the string
class which does what you want.
[color=blue][color=green][color=darkred]
> >> But the fact a junior programmer might not understand Objects as you do
> >> would not prevent you from writing them, would you?[/color]
> >
> > When using C#, one has to use objects. I will almost always try to
> > implement the simplest solution to a problem, unless there is a
> > compelling reason to use a more complex solution. That way, anyone
> > reading the code has to learn relatively little "extra" stuff beyond
> > the language itself.[/color]
>
> That isn't the point.[/color]
It may not be your point, but it's part of my point.
[color=blue]
> We are talking readability here. So don't write any objects. You can use
> the ones you need to, but if you write objects and someone has to maintain
> it, it could be a problem if he doesn't understand objects.[/color]
I'm assuming that "the solution uses .NET" is a given - in other words,
any maintenance engineer should know C# and the basics of .NET. To me
"the basics" don't include regular expressions and memorising all the
details of them. *Some* familiarity can be hoped for, but not knowing
all the constructs - so anything which requires that people *do* know
the regex constructs in order to change things is at a disadvantage.
[color=blue]
> You can write the same code in straight C to do what objects do. We got
> along fine before there were objects. So I think, based on your statements,
> you should write the easier code that some very junior programmer might have
> to read.[/color]
No, we didn't "get along fine" before there were objects. C code is
typically far harder to read than OO code - and where it's not, that's
often because it's effectively written in a semi-OO way, just using
naming to indicate which type of object is being used (just without
polymorphism etc).
[color=blue][color=green]
> > No, they really aren't. for and foreach are well-defined in the C#
> > language specification. If the program is in C# to start with, it is
> > reasonable to assume competency in C# on the part of the reader of the
> > code. It is *not* reasonable to assume competency in regular
> > expressions, and while that wouldn't prevent me from using regular
> > expressions where they provide value, they just *don't* here.[/color]
>
> But I am not writing in C# only. I am writing in .Net.[/color]
So you would assume that everyone who is reading and maintaining your
code knows every class in the .NET framework? I don't.
[color=blue][color=green]
> > Clearly not, as you seem to be keen on using them instead of simple
> > string manipulations all over the place - if I saw anyone using regular
> > expressions rather than String.Replace in the way you've shown in other
> > code posts, that code would never get through code review.
> >[/color]
> Obviously, you micro manage more than I.[/color]
Well, I code review, just as my peers code review. We almost always
find things which can be done better (which works even better when pair
programming). That doesn't indicate that we're not good developers -
just that an extra point of view is always helpful. It also stops us
from getting lazy and implementing something which is just "okay"
rather than as good as it should be.
[color=blue]
> If you would have a problem with our examples, I don't think I would like to
> work in your team.[/color]
Likewise if you don't consider that finding the simplest way of
implementing a solution is worth doing, I wouldn't like to work on your
code.
[color=blue]
> In my area, if your code is reasonable and well written and it follows our
> standards, it's fine.[/color]
Being more complex than it needs to be means that code *isn't*
reasonable and well-written, IMO.
[color=blue][color=green][color=darkred]
> >> >I suspect *very*
> >> > few programs don't do any string manipulation - knowing the string
> >> > methods well is *far* more fundamental to .NET programming than knowing
> >> > regular expressions.
> >>
> >> I agree with part of that and think that regular expressions are just as
> >> important to know.[/color]
> >
> > Why?[/color]
>
> Because they are perfectly valid and as you said before there are some that
> are useful (therefore, you should know them as someone might use them and
> you may have to maintain it).[/color]
Occasionally they're useful. I haven't used a single one in the project
I've been working on for the last six months. On the other hand, I've
used string manipulation all over the place.
I would expect that the number of straight string manipulations in most
code should be *much* higher than the number of regular expressions
used - hence it's more important to thoroughly understand the string
methods than regexes.
[color=blue][color=green]
> >I'm working on a fairly large project which hasn't needed to use
> > regular expressions and wouldn't have benefitted from them once.[/color]
>
> That's your style and position, but may not be someone else's.[/color]
Everyone else in the team certainly feels the same way.
[color=blue][color=green]
> > At that point, if I didn't understand the regular expression, I'd look
> > it up in the documentation. Do you know every part of regular
> > expression syntax off by heart?[/color]
>
> According to your position, you should ban them altogether for ANY use,
> since you can do anything in C# you can do in Regex.[/color]
No, because - as I *keep* saying - there are things you can't do as
*simply* using straight string manipulation. Where it's simpler to use
regexes, I'd use them. Those situations come up occasionally, but not
with the frequency you seem to use regular expressions.
[color=blue][color=green]
> > If they're on my team, I'll tell them to refactor their code to only
> > use them when they're appropriate, frankly.[/color]
>
> Appropriate as defined by you. Why allow them at all?[/color]
See the various places I've exlained that both in this post and many
others.
[color=blue][color=green]
> > If code uses regular expressions when they serve no purpose, it is
> > *not* well written and clean though - it is less maintainable than it
> > might be.
> >[/color]
> They serve a purpose. They do the same as your string routines, so there is
> a pupose. Both are string handling routines.[/color]
No, using regular expressions *instead* of the string handling routines
serves no purpose, just as using a web service to perform addition
would serve no purpose.
There's no advantage in using the regular expression here, and there
*is* a disadvantage.
[color=blue][color=green]
> > And you believe that everyone else does? Again, bear in mind that
> > you're unlikely to be the only person ever to read your code.[/color]
>
> So you should never EVER use Regex. Someone else might read your code.
>
> This is going in circles.[/color]
Yes, because you seem unable to understand the position I've presented
several times.
[color=blue]
> As I said, I would have a problem with someone who couldn't figure out what
> the example we were using was doing.[/color]
But would you have a problem with the same person if they forgot or
didn't check whether, say, '[' needed escaping? I'd find that a fairly
understandable mistake (although I'd hope that unit tests would show
the problem up).
[color=blue][color=green][color=darkred]
> >> Keep regular expressions out of my code?????
> >>
> >> So now you are saying there is no use for it?[/color]
> >
> > Not at all - I'm saying that you shouldn't put regular expressions in
> > your code just for the sake of keeping your hand in. Use them where
> > they're applicable, and only there.[/color]
>
> There either is a use or not. You can't say there is a use for it and then
> brow beat a programmer because he happens to like to use it.[/color]
I certainly can when the programmer uses it where there's no good
reason. There's a time and place to use reflection, but I would
certainly brow-beat a programmer who decided to use it to get the value
of a property which could be done in a safer way (using normal property
access syntax).
[color=blue]
> Has a programmer got to come to you each time he wants to use it to get your
> permission.[/color]
In our team a programmer (including myself) has to get "permission "
every time they want to check anything in. It's called code review, and
it vastly improves the quality of the code.
[color=blue]
> I can see it if he writes some obscure cyptic Regular Expression - but come
> on.[/color]
Cryptic such as "( )" where a straight " " would have been more
readable? Code review should have picked that up.
[color=blue][color=green]
> > But that's *exactly* what you've suggested you should do with regular
> > expressions - use them even when there's no real purpose in doing so,
> > just so that you remember what they look like.[/color]
>
> Sure.
>
> If they are both perfectly valid, I might. Depends on my mood (you should
> really have a problem with that). :)[/color]
I certainly do. "Valid" to me involves the code being as simple as
possible.
[color=blue][color=green]
> > Okay, so you don't memorise it, which means you *do* have to look up
> > which characters require escaping. I think you've just admitted that
> > your code is less maintainable than mine.[/color]
>
> No.
>
> I can maintain my car, but I might still have to look up specs on it.[/color]
But wouldn't it be easier to maintain something which *didn't* require
you to look up anything?
[color=blue][color=green]
> > I would use them when the solution which uses regular expressions is
> > clearer than the solution which doesn't use them. It seems a pretty
> > simple policy to me.[/color]
>
> If they are not readable, you shouldn't use them at all. I personally think
> they are both readable, in this case.[/color]
Readability is not a black and white issue. Something is "more
readable" than something else - in this case, using string manipulation
is more readable (and maintainable, importantly) than using regular
expressions. In other cases, it isn't.
[color=blue][color=green]
> > Those maintaining the code could no doubt understand it after looking
> > at it for a little while, just like they could work out your other
> > regular expressions after looking at them and consulting the
> > documentation - but why are you trying to make their jobs harder? Why
> > are you not concerned that the code you're writing is costing your
> > company money by making it harder to maintain than it needs to be?[/color]
>
> Again, then you feel there is no place for Regex as you can do anything with
> C# that you can do with Regex. As you say, it will always be harder to
> read.[/color]
Where did I say it will *always* be harder to read? Please don't put
words in my mouth, especially when I've expressly stated otherwise
elsewhere.
At times, regular expressions will be easier to understand than the
equivalent string manipulation solution. In this case, they're not.
[color=blue][color=green][color=darkred]
> >> As you said, the two solutions are equal. Your solution is that you MUST
> >> go
> >> with IndexOf. Mine is you can use either.[/color]
> >
> > Well, they're equal in terms of their semantics. They're definitely not
> > equal in terms of maintainability , and as that's important to me, I
> > don't see what's wrong with saying that I'm very strongly in favour of
> > avoiding the less readable/maintainable code.[/color]
>
> I didn't say that.[/color]
Didn't say what?
[color=blue][color=green][color=darkred]
> >> I wasn't referring to this particular issue when I said this.[/color]
> >
> > It would have been nice if you'd indicated that. Do you agree then that
> > it doesn't actually take any more brainpower to come up with
> > String.IndexOf instead of Regex.IsMatch, but in fact it takes *less*
> > brainpower when it comes to maintaining the IndexOf solution?[/color]
>
> In this case, no.[/color]
So you don't think that it would be harder to change the regex code to
look for "hello[there" than it would be to change the IndexOf code in
the same way?
[color=blue]
> In other cases, could be. Would have to look at it. I
> never said that Regex is the best thing out there. I was just saying that
> it is valid and can be readable - can also be cryptic (as can C#).[/color]
And I've never argued with that. I've argued against it being *as*
readable and maintainable in *this* case.
[color=blue][color=green]
> > And of course the answer is "yes, by calling IndexOf multiple times".[/color]
>
> That wasn't the question asked. That was the example that was given and the
> question was can you do it in one statement.
>
> So the answer is no, using IndexOf.[/color]
Okay. But the follow-on answer is "the best way to do it is to use
IndexOf repeatedly" possibly with "and you can always write your own
method to do this if you want".
[color=blue][color=green]
> > Yes, as would a single call to a method which called IndexOf on the
> > string multiple times. I disagree with you - Nicholas wasn't correct in
> > his assessment, as he claimed that the "best bet" would be to use a
> > regular expression. Using regular expressions is just *not* the best
> > bet here - it requires more effort, as I've described repeatedly.[/color]
>
> No, he was correct in his answer to the question. The question was never
> "Which is better", but can you do it .[/color]
His answer talked about the "best bet" - although the question didn't
ask about the best way, his answer did. I disagree with that answer.
[color=blue]
> And you can do a method which called
> IndexOf multiple times. But then it isn't one line, is it?[/color]
You could put it in one line if you wanted to. It wouldn't be as easy
to read, but you could do it.
[color=blue][color=green]
> > Are you suggesting that maintainability isn't something that should be
> > considered? Do you *really* want to look for "something1 ",
> > "something2 " and "something3 " or were they (as I suspect) just
> > examples, and the real values could easily have dots, brackets etc in?[/color]
>
> I don't really remember what the context was originally. But I know they
> didn't have dots and brackets in it.[/color]
And wouldn't ever?
[color=blue][color=green][color=darkred]
> >> What if you wanted to change "something1 " to "something\ ". Same problem.[/color]
> >
> > Well, half the problem with IndexOf than it is with regular
> > expressions. With regular expressions, you'd need to know that not only
> > does backslash need escaping in C#, it also needs escaping in regular
> > expressions.
> >
> > IndexOf: "something\ \" or @"something\ "
> > Regex: "something\ \\\" or @"something\ \"
> >
> > Once again, the IndexOf version is easier to understand - there's less
> > to mentally unescape to work out what's actually being asked for.
> >[/color]
> Splitting hairs, now. Both are the same, as far as I can see (here).[/color]
You don't think that having to count 4 backslashes is even slightly
harder than only counting 2? I can spot a double-backslash without
doing any double-checking. I'd always be careful when I needed four.
[color=blue][color=green][color=darkred]
> >> And if escapes were a problem (if it were me) I would have a little sheet
> >> that showed them at my desk within easy reach.[/color]
> >
> > Whereas by needing to know less (just the C# escapes) it's really easy
> > to memorise everything I need to know to solve this situation.[/color]
>
> That's true, but then you would only know C#. And if that is your aim.
> That's fine.[/color]
My aim is to only *need* to know as little as possible. The rest is
available where necessary.
[color=blue][color=green]
> > Yup, but it's something that isn't used in string literals other than
> > for regular expressions. It's an extra thing to bear in mind
> > unnecessarily.[/color]
>
> No room for it, huh?[/color]
Not when there's a simpler solution, no.
[color=blue][color=green]
> > While I'm leaving the exact original question, it's far from out of the
> > question that the original code wouldn't need to be changed to use a
> > variable to be searched for some time. At that point, can you guarantee
> > that your team would get it right? They'd need to be on their guard
> > when using regular expressions - they wouldn't need to be on their
> > guard using IndexOf.[/color]
>
> Right. No one makes mistakes with IndexOf.[/color]
More rarely than with regular expressions.
[color=blue][color=green]
> > They aren't as readable *in this case*. In other, more complicated
> > situations, the version which only used IndexOf would be harder to read
> > than the regular expression version.[/color]
>
> But your problem was that it would be hard for other programmers to read.
> If they can read your more complicated version, this one should be easy.[/color]
<sigh> It's a matter of degree, as I keep saying. It's a case of how
much effort needs to be put in to understand something.
[color=blue][color=green]
> > You seem to fail to grasp the "make it as simple as possible" concept.
> > It's not a case of maintenance engineers being idiots - it's about
> > presenting them with fewer possible risks. Why leave them a trap to
> > fall into when you can write simpler code which is easier to change
> > later on?[/color]
>
> No.
>
> I just find it as simple, in this case and you don't.[/color]
I would be willing to wager large amounts of money on others
(particularly junior programmers) finding it less simple though. I'm
absolutely certain that if thousands of programmers had to maintain the
IndexOf version and change it to look for "foo.bar", fewer would make a
mistake than thousands of equivalent programmers maintaining the
regular expression version.
Are you absolutely certain that the regular expression *wouldn't* prove
more bug-prone?
[color=blue][color=green]
> > But you're pushing for regular expressions in *this* situation, or at
> > least saying it's just as good as using IndexOf. You've also shown in
> > your other code that you use regular expressions unnecessarily for
> > replacement, making a simple two-step replacement into a complicated
> > single-step replacement where the number of characters which *aren't*
> > just plain text is greater than the number of characters which are.[/color]
>
> No. Not pushing. But think they are equivelant in this case. As you said
> earlier, I am sure others would disagree. But I don't think that the
> difference is significant enough, in this case, even if I were to agree on
> which is easier, to preclude it.[/color]
To me, it's definitely signifiant. Using regular expressions here
introduces risk for no benefit.
[color=blue][color=green][color=darkred]
> >> Can't have it both ways. If you allow Regular Expressions, you shouldn't
> >> have a problem if a programmer used the Regex or IndexOf in our example.
> >> Anyone maintaining the "USEFUL" ones would have zero problems with this
> >> one.[/color]
> >
> > How very black and white of you. Do you really have no concept of
> > someone being able to understand something, but having a harder time
> > understanding it one way than the other?
> >[/color]
> Who?
>
> The person who can understand Regex if complicated, but would be trashed
> trying to figure out our little example.
>
> Bit of a stretch there.[/color]
Again, you're being black and white. I'm not saying that people
*couldn't* understand the regular expression - although they're more
likely to make a simple mistake without thinking about it. I'm saying
that they'll need to put more effort into understanding it than a
straight IndexOf.
[color=blue][color=green]
> > Yes - the complicated cases where I've already said that regular
> > expressions are useful![/color]
>
> Just make sure the programmer that can't handle the easy Regex doesn't see
> that one.[/color]
I would hope that anyone maintaining a complex regular expression will
double-check what's going on. It's easy to conceive of someone
maintaining a simple one failing to do so.
[color=blue][color=green]
> > No, just allow them where they make sense. Note that if you only use
> > them where they're going to be doing something fairly involved, it's
> > much less likely that an engineer will forget that he's actually
> > dealing with a regular expression than with a simple string.[/color]
>
> Already dealt with.[/color]
Where?
[color=blue][color=green]
> > But regular expressions are by their very nature more complicated than
> > a simple String.IndexOf call. If they weren't they wouldn't be as
> > powerful as they are.[/color]
>
> Write and vanilla C# is less complicated than writing objects, but we still
> do them.[/color]
No, it's not less complicated. If you avoided using objects, the code
would be *much* harder to read and maintain.
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
tshad <tscheiderich@f tsolutions.com> wrote:[color=blue][color=green][color=darkred]
> >> When I talk about a Programming Language - I am talking about a
> >> Procedural
> >> Language (C, Fortran, VB, Pascal, etc.).[/color]
> >
> > So you wouldn't regard LISP as a programming language, just because
> > it's functional rather than procedural?[/color]
>
> I don't know much about LISP, but Mathematics is also a language, but not
> the same way as English and German are.[/color]
Indeed.
[color=blue][color=green]
> > Of course, you didn't even specify "programmin g language" before.[/color]
>
> True.
>
> But I did specify, that it depends on how you define it.[/color]
True.
[color=blue][color=green]
> > Right. Immediately the IndexOf value is more readable, by more clearly
> > separating the three separate strings which are being searched on.
> > (Oliver Sturm's version is more readable than that[/color]
>
> I assume you mean "if (Regex.IsMatch( myString, @"something[123]"))".[/color]
No, I mean:
Yes, where the string itself is separated onto three lines.
[color=blue]
> But actually they are both Olivers.
>
> I don't agree there. I think the Regex is just as readable, as long as you
> have a bit of Regular Expression understanding, obviously. I also think
> that if you understand C and didn't understand Regex - you would get what it
> is saying (IsMatch is pretty much of a giveaway). Much than if you didn't
> understand C and so the IndexOf - which doesn't really telling you what it
> is doing.[/color]
Yes it does, it's finding the index of one string within another.
[color=blue]
> IsMatch is much more understandable term than IndexOf.[/color]
The name is as understandable, but the exact semantics are *much* more
obscure. The name doesn't suggest that you can't just put a only in
there and expect it to only match a dot for instance, does it?
[color=blue][color=green][color=darkred]
> >> Again, why do I need a compelling reason. If I have the solution and it
> >> happens to be Regex, I would use it, I wouldn't necessarily say to
> >> myself -
> >> "Is there perhaps a more readable way to write this? I wonder if Jim
> >> will
> >> be able to read this or not."[/color]
> >
> > Then I'm afraid that's your problem. It sounds like you're basically
> > admitting that you're not that interested in readability. Personally, I
> > like writing code which is elegant but easy to maintain. Having *a*
> > solution which happens to work isn't enough when there are obviously
> > others available which could well be simpler.[/color]
>
> I never said that.[/color]
You said that when you have a solution, you won't consider whether a
more readable way of writing it. To me, that demonstrates that you
don't care very much about readability.
[color=blue]
> I never said readability is not an issue, but I am not going to write "Cat
> in the Hat" instead of a novel so that the programmers with the simplest of
> experience can read it. But I am not going to write cryptic code either so
> they can't read it.[/color]
If the "Cat in the Hat" does the job as well as the novel and is easier
to read, why on earth would you want to write the novel?
[color=blue]
> I assume there are company standards to program by and I would follow that.[/color]
There aren't usually company standards down to the level of when to use
regular expressions.
[color=blue][color=green]
> >Having *a*
> > solution which happens to work isn't enough when there are obviously
> > others available which could well be simpler.[/color]
>
> I am not writing simple code, I am writing code to handle a problem. I
> prefer to write good code not simple code. Sometimes they are synonymous,
> sometimes they aren't.[/color]
I disagree - simple code that works (as well as the more complicated
code) is always good. Note that this is in terms of implementation, not
design - there's sometimes a very simple but inelegant design which
ends up costing a lot more work in the long run. That's a different
matter.
[color=blue]
> But in our case, I still them as equally readable.[/color]
You still haven't said whether you see them as equally readable *and
maintainable* to others though.
[color=blue][color=green]
> > Far more time is spent maintaining code than writing it in the first
> > place. Taking the attitude you take above just isn't cost-effective in
> > the long run.[/color]
>
> Don't agree there.[/color]
With which bit? If you're going to disagree with the first sentence
quoted, we really don't have much basis for discussion. I thought it
was pretty much universally accepted these days that code almost always
spends more time in maintenance than in original coding. That's why I'm
always happy to spend a bit more time refactoring working code to make
it easier to maintain.
[color=blue][color=green][color=darkred]
> >> No pushing. No more than your pushing not using it.[/color]
> >
> > But I'll readily admit to pushing the (IMO simpler) solution, for this
> > particular situation. So are you actually admitting that you *are*
> > pushing the use of regular expressions here?
> >[/color]
> In your opinion (as you say).
>
> And you obviously are not listening. I am not pushing either side. I have
> been saying over and over that in this situation, they are the same (IMO).[/color]
But that *is* pushing regular expressions from my point of view, where
they shouldn't be an option.
Consider an exaggerated equivalent situation. Suppose we were
discussing how to implement addition. Suppose I thought that just using
the expression x+y was the easiest way of doing things, and you thought
it was just as easy to write a remote web service which took two
integers. By *not* ruling out the more complex solution, you're
*effectively* pushing it - at least pushing it as an equally valid
option.
[color=blue]
> I am not pushing Regex nor am I ruling them out. You however, can't make up
> your mind. One minute you say that something as simple as the example we
> are using is too complex for a programmer and then proceed to say that you
> would use Regex in other situations (which would have to be more
> complicated), makes no sense.[/color]
<sigh> I don't know whether you're intentionally missing the point or
whether I'm genuinely not getting through.
There is always risk associated with changing code. When writing code,
you should try to reduce the risk that future changes will incur. That
means making the code as simple as possible, and easy to change.
In some cases a regular expression will be a lot simpler to read and
change than the equivalent "primitive string manipulation" code. Those
cases would usually be where the string manipulation involves several
steps, often nested loops etc. There, the complexity of regular
expressions (which is still there) is less than the complexity of the
primitive solution.
In this case, however, the primitive solution is very simple and
understandable. Changing it to search for a different string or an
extra string (or even a string passed in as a parameter) is trivial.
Changing the regular expression is not.
[color=blue][color=green]
> > So again, the code could be made more readable even by just modifying
> > the existing regex replacement, let alone by replacing the regular
> > expressions with simple String.Replace calls. Had they been
> > String.Replace calls, the meaning of the second line would have been
> > unambiguous - you'd have had to write it the simple way to start with.
> >[/color]
> I am not saying there may not be other ways to write the code. As I said, I
> often rewrite my own code later as I see a way I like better that I may not
> have thought of at the time I wrote it. Many times it isn't better code,
> just different.[/color]
In this case though, it *would* be better - it would be simpler to
understand, and simpler to write in the first place.
For instance, I wouldn't have had to consider whether the brackets were
doing something clever or not. I had to look up .NET regular
expressions just to check the meaning in this case. Do you really
believe that a solution which *doesn't* involve that extra thought
isn't better?
[color=blue][color=green]
> > Note that your first replacement will replace two tabs with a single
> > space, but leave one tab alone, by the way. It would be better to
> > replace "\s+" with the space, IMO.[/color]
>
> Probably true. I am not a Regex expert. That was what I came up with at
> the time.[/color]
And that's part of the risk - that someone doesn't put enough effort
into the regex to get the *actually* desired behaviour. Where the
alternative is a complex solution, it makes a lot of sense to put
significant effort into getting the regex right. When you could do the
same thing with a few string operations, it's just not worth it.
(For this first line, a regex is probably the best way to go - but you
need to think about it more closely.)
[color=blue][color=green]
> > I have had to look it up if you hadn't been answering the question
> > though. Why make the code harder to understand in the first place? If
> > you want to replace a space with " or ", just use
> > keywords = keywords.Replac e (" ", " or ");
> > Much more straightforward .
> >[/color]
> Even in C, which I have used for years, I have to look up parameters to make
> sure I have the right parameters and have them in the right order.[/color]
Usually intellisense can help you with that though - it *doesn't* start
explaining the details of regular expressions though.
[color=blue]
> As I said, the Parens were probably a mistake and may have made some changes
> to the line and left the parens in. I agree yours is the correct one.[/color]
And if you weren't taking "use regular expressions" as your default
position, you wouldn't have made the mistake in the first place. The
first thing you should try to think of is the simplest one. You want to
manipulate a string, so ask yourself if there's anything in the string
class which does what you want.
[color=blue][color=green][color=darkred]
> >> But the fact a junior programmer might not understand Objects as you do
> >> would not prevent you from writing them, would you?[/color]
> >
> > When using C#, one has to use objects. I will almost always try to
> > implement the simplest solution to a problem, unless there is a
> > compelling reason to use a more complex solution. That way, anyone
> > reading the code has to learn relatively little "extra" stuff beyond
> > the language itself.[/color]
>
> That isn't the point.[/color]
It may not be your point, but it's part of my point.
[color=blue]
> We are talking readability here. So don't write any objects. You can use
> the ones you need to, but if you write objects and someone has to maintain
> it, it could be a problem if he doesn't understand objects.[/color]
I'm assuming that "the solution uses .NET" is a given - in other words,
any maintenance engineer should know C# and the basics of .NET. To me
"the basics" don't include regular expressions and memorising all the
details of them. *Some* familiarity can be hoped for, but not knowing
all the constructs - so anything which requires that people *do* know
the regex constructs in order to change things is at a disadvantage.
[color=blue]
> You can write the same code in straight C to do what objects do. We got
> along fine before there were objects. So I think, based on your statements,
> you should write the easier code that some very junior programmer might have
> to read.[/color]
No, we didn't "get along fine" before there were objects. C code is
typically far harder to read than OO code - and where it's not, that's
often because it's effectively written in a semi-OO way, just using
naming to indicate which type of object is being used (just without
polymorphism etc).
[color=blue][color=green]
> > No, they really aren't. for and foreach are well-defined in the C#
> > language specification. If the program is in C# to start with, it is
> > reasonable to assume competency in C# on the part of the reader of the
> > code. It is *not* reasonable to assume competency in regular
> > expressions, and while that wouldn't prevent me from using regular
> > expressions where they provide value, they just *don't* here.[/color]
>
> But I am not writing in C# only. I am writing in .Net.[/color]
So you would assume that everyone who is reading and maintaining your
code knows every class in the .NET framework? I don't.
[color=blue][color=green]
> > Clearly not, as you seem to be keen on using them instead of simple
> > string manipulations all over the place - if I saw anyone using regular
> > expressions rather than String.Replace in the way you've shown in other
> > code posts, that code would never get through code review.
> >[/color]
> Obviously, you micro manage more than I.[/color]
Well, I code review, just as my peers code review. We almost always
find things which can be done better (which works even better when pair
programming). That doesn't indicate that we're not good developers -
just that an extra point of view is always helpful. It also stops us
from getting lazy and implementing something which is just "okay"
rather than as good as it should be.
[color=blue]
> If you would have a problem with our examples, I don't think I would like to
> work in your team.[/color]
Likewise if you don't consider that finding the simplest way of
implementing a solution is worth doing, I wouldn't like to work on your
code.
[color=blue]
> In my area, if your code is reasonable and well written and it follows our
> standards, it's fine.[/color]
Being more complex than it needs to be means that code *isn't*
reasonable and well-written, IMO.
[color=blue][color=green][color=darkred]
> >> >I suspect *very*
> >> > few programs don't do any string manipulation - knowing the string
> >> > methods well is *far* more fundamental to .NET programming than knowing
> >> > regular expressions.
> >>
> >> I agree with part of that and think that regular expressions are just as
> >> important to know.[/color]
> >
> > Why?[/color]
>
> Because they are perfectly valid and as you said before there are some that
> are useful (therefore, you should know them as someone might use them and
> you may have to maintain it).[/color]
Occasionally they're useful. I haven't used a single one in the project
I've been working on for the last six months. On the other hand, I've
used string manipulation all over the place.
I would expect that the number of straight string manipulations in most
code should be *much* higher than the number of regular expressions
used - hence it's more important to thoroughly understand the string
methods than regexes.
[color=blue][color=green]
> >I'm working on a fairly large project which hasn't needed to use
> > regular expressions and wouldn't have benefitted from them once.[/color]
>
> That's your style and position, but may not be someone else's.[/color]
Everyone else in the team certainly feels the same way.
[color=blue][color=green]
> > At that point, if I didn't understand the regular expression, I'd look
> > it up in the documentation. Do you know every part of regular
> > expression syntax off by heart?[/color]
>
> According to your position, you should ban them altogether for ANY use,
> since you can do anything in C# you can do in Regex.[/color]
No, because - as I *keep* saying - there are things you can't do as
*simply* using straight string manipulation. Where it's simpler to use
regexes, I'd use them. Those situations come up occasionally, but not
with the frequency you seem to use regular expressions.
[color=blue][color=green]
> > If they're on my team, I'll tell them to refactor their code to only
> > use them when they're appropriate, frankly.[/color]
>
> Appropriate as defined by you. Why allow them at all?[/color]
See the various places I've exlained that both in this post and many
others.
[color=blue][color=green]
> > If code uses regular expressions when they serve no purpose, it is
> > *not* well written and clean though - it is less maintainable than it
> > might be.
> >[/color]
> They serve a purpose. They do the same as your string routines, so there is
> a pupose. Both are string handling routines.[/color]
No, using regular expressions *instead* of the string handling routines
serves no purpose, just as using a web service to perform addition
would serve no purpose.
There's no advantage in using the regular expression here, and there
*is* a disadvantage.
[color=blue][color=green]
> > And you believe that everyone else does? Again, bear in mind that
> > you're unlikely to be the only person ever to read your code.[/color]
>
> So you should never EVER use Regex. Someone else might read your code.
>
> This is going in circles.[/color]
Yes, because you seem unable to understand the position I've presented
several times.
[color=blue]
> As I said, I would have a problem with someone who couldn't figure out what
> the example we were using was doing.[/color]
But would you have a problem with the same person if they forgot or
didn't check whether, say, '[' needed escaping? I'd find that a fairly
understandable mistake (although I'd hope that unit tests would show
the problem up).
[color=blue][color=green][color=darkred]
> >> Keep regular expressions out of my code?????
> >>
> >> So now you are saying there is no use for it?[/color]
> >
> > Not at all - I'm saying that you shouldn't put regular expressions in
> > your code just for the sake of keeping your hand in. Use them where
> > they're applicable, and only there.[/color]
>
> There either is a use or not. You can't say there is a use for it and then
> brow beat a programmer because he happens to like to use it.[/color]
I certainly can when the programmer uses it where there's no good
reason. There's a time and place to use reflection, but I would
certainly brow-beat a programmer who decided to use it to get the value
of a property which could be done in a safer way (using normal property
access syntax).
[color=blue]
> Has a programmer got to come to you each time he wants to use it to get your
> permission.[/color]
In our team a programmer (including myself) has to get "permission "
every time they want to check anything in. It's called code review, and
it vastly improves the quality of the code.
[color=blue]
> I can see it if he writes some obscure cyptic Regular Expression - but come
> on.[/color]
Cryptic such as "( )" where a straight " " would have been more
readable? Code review should have picked that up.
[color=blue][color=green]
> > But that's *exactly* what you've suggested you should do with regular
> > expressions - use them even when there's no real purpose in doing so,
> > just so that you remember what they look like.[/color]
>
> Sure.
>
> If they are both perfectly valid, I might. Depends on my mood (you should
> really have a problem with that). :)[/color]
I certainly do. "Valid" to me involves the code being as simple as
possible.
[color=blue][color=green]
> > Okay, so you don't memorise it, which means you *do* have to look up
> > which characters require escaping. I think you've just admitted that
> > your code is less maintainable than mine.[/color]
>
> No.
>
> I can maintain my car, but I might still have to look up specs on it.[/color]
But wouldn't it be easier to maintain something which *didn't* require
you to look up anything?
[color=blue][color=green]
> > I would use them when the solution which uses regular expressions is
> > clearer than the solution which doesn't use them. It seems a pretty
> > simple policy to me.[/color]
>
> If they are not readable, you shouldn't use them at all. I personally think
> they are both readable, in this case.[/color]
Readability is not a black and white issue. Something is "more
readable" than something else - in this case, using string manipulation
is more readable (and maintainable, importantly) than using regular
expressions. In other cases, it isn't.
[color=blue][color=green]
> > Those maintaining the code could no doubt understand it after looking
> > at it for a little while, just like they could work out your other
> > regular expressions after looking at them and consulting the
> > documentation - but why are you trying to make their jobs harder? Why
> > are you not concerned that the code you're writing is costing your
> > company money by making it harder to maintain than it needs to be?[/color]
>
> Again, then you feel there is no place for Regex as you can do anything with
> C# that you can do with Regex. As you say, it will always be harder to
> read.[/color]
Where did I say it will *always* be harder to read? Please don't put
words in my mouth, especially when I've expressly stated otherwise
elsewhere.
At times, regular expressions will be easier to understand than the
equivalent string manipulation solution. In this case, they're not.
[color=blue][color=green][color=darkred]
> >> As you said, the two solutions are equal. Your solution is that you MUST
> >> go
> >> with IndexOf. Mine is you can use either.[/color]
> >
> > Well, they're equal in terms of their semantics. They're definitely not
> > equal in terms of maintainability , and as that's important to me, I
> > don't see what's wrong with saying that I'm very strongly in favour of
> > avoiding the less readable/maintainable code.[/color]
>
> I didn't say that.[/color]
Didn't say what?
[color=blue][color=green][color=darkred]
> >> I wasn't referring to this particular issue when I said this.[/color]
> >
> > It would have been nice if you'd indicated that. Do you agree then that
> > it doesn't actually take any more brainpower to come up with
> > String.IndexOf instead of Regex.IsMatch, but in fact it takes *less*
> > brainpower when it comes to maintaining the IndexOf solution?[/color]
>
> In this case, no.[/color]
So you don't think that it would be harder to change the regex code to
look for "hello[there" than it would be to change the IndexOf code in
the same way?
[color=blue]
> In other cases, could be. Would have to look at it. I
> never said that Regex is the best thing out there. I was just saying that
> it is valid and can be readable - can also be cryptic (as can C#).[/color]
And I've never argued with that. I've argued against it being *as*
readable and maintainable in *this* case.
[color=blue][color=green]
> > And of course the answer is "yes, by calling IndexOf multiple times".[/color]
>
> That wasn't the question asked. That was the example that was given and the
> question was can you do it in one statement.
>
> So the answer is no, using IndexOf.[/color]
Okay. But the follow-on answer is "the best way to do it is to use
IndexOf repeatedly" possibly with "and you can always write your own
method to do this if you want".
[color=blue][color=green]
> > Yes, as would a single call to a method which called IndexOf on the
> > string multiple times. I disagree with you - Nicholas wasn't correct in
> > his assessment, as he claimed that the "best bet" would be to use a
> > regular expression. Using regular expressions is just *not* the best
> > bet here - it requires more effort, as I've described repeatedly.[/color]
>
> No, he was correct in his answer to the question. The question was never
> "Which is better", but can you do it .[/color]
His answer talked about the "best bet" - although the question didn't
ask about the best way, his answer did. I disagree with that answer.
[color=blue]
> And you can do a method which called
> IndexOf multiple times. But then it isn't one line, is it?[/color]
You could put it in one line if you wanted to. It wouldn't be as easy
to read, but you could do it.
[color=blue][color=green]
> > Are you suggesting that maintainability isn't something that should be
> > considered? Do you *really* want to look for "something1 ",
> > "something2 " and "something3 " or were they (as I suspect) just
> > examples, and the real values could easily have dots, brackets etc in?[/color]
>
> I don't really remember what the context was originally. But I know they
> didn't have dots and brackets in it.[/color]
And wouldn't ever?
[color=blue][color=green][color=darkred]
> >> What if you wanted to change "something1 " to "something\ ". Same problem.[/color]
> >
> > Well, half the problem with IndexOf than it is with regular
> > expressions. With regular expressions, you'd need to know that not only
> > does backslash need escaping in C#, it also needs escaping in regular
> > expressions.
> >
> > IndexOf: "something\ \" or @"something\ "
> > Regex: "something\ \\\" or @"something\ \"
> >
> > Once again, the IndexOf version is easier to understand - there's less
> > to mentally unescape to work out what's actually being asked for.
> >[/color]
> Splitting hairs, now. Both are the same, as far as I can see (here).[/color]
You don't think that having to count 4 backslashes is even slightly
harder than only counting 2? I can spot a double-backslash without
doing any double-checking. I'd always be careful when I needed four.
[color=blue][color=green][color=darkred]
> >> And if escapes were a problem (if it were me) I would have a little sheet
> >> that showed them at my desk within easy reach.[/color]
> >
> > Whereas by needing to know less (just the C# escapes) it's really easy
> > to memorise everything I need to know to solve this situation.[/color]
>
> That's true, but then you would only know C#. And if that is your aim.
> That's fine.[/color]
My aim is to only *need* to know as little as possible. The rest is
available where necessary.
[color=blue][color=green]
> > Yup, but it's something that isn't used in string literals other than
> > for regular expressions. It's an extra thing to bear in mind
> > unnecessarily.[/color]
>
> No room for it, huh?[/color]
Not when there's a simpler solution, no.
[color=blue][color=green]
> > While I'm leaving the exact original question, it's far from out of the
> > question that the original code wouldn't need to be changed to use a
> > variable to be searched for some time. At that point, can you guarantee
> > that your team would get it right? They'd need to be on their guard
> > when using regular expressions - they wouldn't need to be on their
> > guard using IndexOf.[/color]
>
> Right. No one makes mistakes with IndexOf.[/color]
More rarely than with regular expressions.
[color=blue][color=green]
> > They aren't as readable *in this case*. In other, more complicated
> > situations, the version which only used IndexOf would be harder to read
> > than the regular expression version.[/color]
>
> But your problem was that it would be hard for other programmers to read.
> If they can read your more complicated version, this one should be easy.[/color]
<sigh> It's a matter of degree, as I keep saying. It's a case of how
much effort needs to be put in to understand something.
[color=blue][color=green]
> > You seem to fail to grasp the "make it as simple as possible" concept.
> > It's not a case of maintenance engineers being idiots - it's about
> > presenting them with fewer possible risks. Why leave them a trap to
> > fall into when you can write simpler code which is easier to change
> > later on?[/color]
>
> No.
>
> I just find it as simple, in this case and you don't.[/color]
I would be willing to wager large amounts of money on others
(particularly junior programmers) finding it less simple though. I'm
absolutely certain that if thousands of programmers had to maintain the
IndexOf version and change it to look for "foo.bar", fewer would make a
mistake than thousands of equivalent programmers maintaining the
regular expression version.
Are you absolutely certain that the regular expression *wouldn't* prove
more bug-prone?
[color=blue][color=green]
> > But you're pushing for regular expressions in *this* situation, or at
> > least saying it's just as good as using IndexOf. You've also shown in
> > your other code that you use regular expressions unnecessarily for
> > replacement, making a simple two-step replacement into a complicated
> > single-step replacement where the number of characters which *aren't*
> > just plain text is greater than the number of characters which are.[/color]
>
> No. Not pushing. But think they are equivelant in this case. As you said
> earlier, I am sure others would disagree. But I don't think that the
> difference is significant enough, in this case, even if I were to agree on
> which is easier, to preclude it.[/color]
To me, it's definitely signifiant. Using regular expressions here
introduces risk for no benefit.
[color=blue][color=green][color=darkred]
> >> Can't have it both ways. If you allow Regular Expressions, you shouldn't
> >> have a problem if a programmer used the Regex or IndexOf in our example.
> >> Anyone maintaining the "USEFUL" ones would have zero problems with this
> >> one.[/color]
> >
> > How very black and white of you. Do you really have no concept of
> > someone being able to understand something, but having a harder time
> > understanding it one way than the other?
> >[/color]
> Who?
>
> The person who can understand Regex if complicated, but would be trashed
> trying to figure out our little example.
>
> Bit of a stretch there.[/color]
Again, you're being black and white. I'm not saying that people
*couldn't* understand the regular expression - although they're more
likely to make a simple mistake without thinking about it. I'm saying
that they'll need to put more effort into understanding it than a
straight IndexOf.
[color=blue][color=green]
> > Yes - the complicated cases where I've already said that regular
> > expressions are useful![/color]
>
> Just make sure the programmer that can't handle the easy Regex doesn't see
> that one.[/color]
I would hope that anyone maintaining a complex regular expression will
double-check what's going on. It's easy to conceive of someone
maintaining a simple one failing to do so.
[color=blue][color=green]
> > No, just allow them where they make sense. Note that if you only use
> > them where they're going to be doing something fairly involved, it's
> > much less likely that an engineer will forget that he's actually
> > dealing with a regular expression than with a simple string.[/color]
>
> Already dealt with.[/color]
Where?
[color=blue][color=green]
> > But regular expressions are by their very nature more complicated than
> > a simple String.IndexOf call. If they weren't they wouldn't be as
> > powerful as they are.[/color]
>
> Write and vanilla C# is less complicated than writing objects, but we still
> do them.[/color]
No, it's not less complicated. If you avoided using objects, the code
would be *much* harder to read and maintain.
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Comment