|
|
Comments and Discussions
|
|
 |

|
Allways the same discussion about this topic... But I can't resist to share my opinion.
I'm C++ and C# developer and I use different prefixing for each language. What I use for C# is not really HN but it leads to the same benefit:
* Code is not only seen in an IDE - it's text, so sometime it is printed or seen in an text editor which doesn't "know" about "Code".
* The m_ or _ or m (or whatever you use) prefix is very common. When I look at the Code of my junior developers I think it helps them a lot. The newbies are often confused by variable scope.
* I do a lot of GUI programming (Sometimes several hundred Controls on a Form (Cause of the Framework we use)). So I use a prefixing Schema for the Controls too. Benefit: All Controls of the same type are together in the Intellisense - same with all Variables of the same type if you use a prefix!
So .NET style-guide is a most time a good thing but on HN i TOTALLY DISAGREE! I think what is really important in programming is a very strict style you use for yourself. This helps a lot to decide what variable names to use. I have no problem thinking about knew "names" after a type conversion or something similar. And it's easier to spot wrong conversions (iVariable = fVariable)
Think about it ...
string strError;
int iError;
Exception exError;
string strLine;
string[] astrLine = strLine.Split(",".ToCharArray());
|
|
|
|

|
This article is not the place for this this discussion since it isn't about this article. Please take this to the appropriate forum on the site.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Yes you are right. Sorry. I just wanted to answer to the "Improvement" discussion on this article.
|
|
|
|

|
I realize that you're coming from C++, but honestly, this whole class is obviated by stuff that's readily available in the framework. I'm not against baking one's own, but when you don't have to, I wouldn't recommend doing so.
string original = "foo,bar,baz,bally,bot";
List<string> foozle = new List<string> ( original.Split( new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries) );
if (foozle.Contains("bar"))
Console.Out.WriteLine("It's got a bar!");
int index = foozle.IndexOf("bally");
Console.Out.WriteLine("bally is at position {0}", index);
foozle.Remove("foo");
foozle.Sort();
foozle.Reverse();
foreach( string s in foozle)
{
Console.Out.WriteLine("Found: {0}", s);
}
string newOriginal = string.Join( "," , foozle.ToArray());
Console.Out.WriteLine("The original string, without \"foo\" is now:\n '{0}'", newOriginal);
</string></string>
|
|
|
|

|
Yes, I knew about the string.Split() function before I did this. Notable differences between string.Split() and this class is that this class allows delimiter *strings*, quoted delimited strings, and it allows you to add/delete/insert new sub-strings within the original string.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
so I guess you can argue that two calls are better, but, string split allows Chars or Strings, even Multiple Chars or Strings, as well as the intrinsic behavior modifier to create empty strings or ignore empty entires If you get your array of strings, which also happens to implement IEnumerable<String> then you can pass it as a constructor directly to a list which as you can see, actually does all your class does, including allowing you to add/remove/insert/delete/sort/reverse/indexof. One function call later, albeit on a different class (string) instead of list<string>, then you can slap them all back together. If you like to see it arranged the way you have it, that's fine, but you're really duplicating stuff that's already anticipated and implemented.
|
|
|
|

|
The beauty in having access to the source code is that you can mold it in your own image.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Your message caused me to go back and revisit the code. You are indeed correct that the Split function allows string delimiters, but it does not support quoted strings. Even so, I re-evaluated the Parse function and shortened it to just 25 lines of code.
As for the sorting, reversing, and ignoring of empty fields, that's not what this parser is all about. It's for strings that need to be parsed and processed in the original order of appearance, and missing fields are expected.
I'll be posting the new code sometime today.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Article updated, and new code posted.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
I think you're mistaken.
Quoted strings are not supported by string.Split.
Delimeters that appear within quoted substrings are not treated as delimiters.
|
|
|
|

|
His comment did cause a major re-write and resulting simplification of the class, and simplification is always a good thing.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Base on comments received after I initially uploaded the article, I've made several sweeping changes. Note that the download filename has also changed.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
I'll be implementing a number of suggestions already posted.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Since you're coming from C++ I just want to let you know a few things.
1- ArrayList is bad:
Since your project is in .NET 2.0 you should really use the generic List type ( System.Collections.Generic.List<T> )
This way you don't need to do ToString() or cast if you are using int/double etc
2- Hungarion Notation is bad:
Some people still use m_ for members (it's even used in .NET for fields) but forget the s/c/...
public string GetField(int nIndex)
use
public string GetField(int index)
instead
And get rid of the C prefix for classes, the only exception is I prefix for interfaces.
3- Destructor is bad:
Only use it if you need to clean up unmanaged resources, in this class it's totally unneeded, the garbage collector will clean up your class.
4- Enums:
Declare it outside and again, try to use the normal .NET notation:
public enum DeleteAction { DeleteAll, DeleteFirst, DeleteLast }
5- XML Comments:
Instead of:
//--------------------------------------------------------------------------------
// Re-parses the string
//--------------------------------------------------------------------------------
public int ResetOriginalString(string sVal, string sDelimiter, char cQuote)
use
/// <summary>
/// Re-parses the string.
/// </summary>
public int ResetOriginalString(string value, string delimiter, char quote)
But it's a nice helper class
Great article, got my 5
|
|
|
|

|
Steve Hansen wrote: 1- ArrayList is bad
I'll look into that tonight after work. I have a question - beyond the ToString() thing, what makes ArrayList "bad"?
Steve Hansen wrote: 2- Hungarion Notation is bad
I like it. It lets me know what type the variable is. This isn't technically "bad" as much as it is "personal preference".
Steve Hansen wrote: 3- Destructor is bad
It may be unnecessary, but I don't see it as "bad", but okay - I guess I'll get rid of it.
Steve Hansen wrote: 4- Enums:
Declare it outside
Outside of what? The namespace? The class? I tried outside the class and the compiler choked/puked on me. In C++, enums are typically defined in the class in which they're used.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
John Simmons / outlaw programmer wrote: I have a question - beyond the ToString() thing, what makes ArrayList "bad"?
Any object added to it has to be upcast to Object. For value types, this mandates boxing which is an expensive process (compared to a cast). And for boxed objects, they then have to be unboxed during retrieval. Boxing, unboxing and all the casting that's involved results in poorer performance for large collections.
Also, there's no compile-time type checking possible since everything in an ArrayList is an Object.
John Simmons / outlaw programmer wrote: Outside of what? The namespace? The class? I tried outside the class and the compiler choked/puked on me.
Enums are typically defined outside the class (within the namespace). What errors did you get?
John Simmons / outlaw programmer wrote: It may be unnecessary, but I don't see it as "bad", but okay - I guess I'll get rid of it.
This destructor is actually not one - it's a finalizer. Any type with a finalizer will have a slight performance loss because during garbage collection types with finalizers are not immediately cleaned up, instead they are promoted to a finalization queue. And they are freed only during a later GC cycle. Thus any types with finalizers need at least 2 GC cycles to be freed. So in your case you are un-wantedly degrading the performance of the class by having a finalizer where one's not really needed.
John Simmons / outlaw programmer wrote: I like it. It lets me know what type the variable is. This isn't technically "bad" as much as it is "personal preference".
Initially I thought like that too. But the tech architect at our place helped change my mind. When writing MFC code I now follow the MFC style naming, but when writing .NET code, I try and follow .NET naming conventions as far as possible - though I still accidentally mix them up on occasions In the long run you'll see that it's probably better to stick to .NET conventions for your managed assemblies.
|
|
|
|

|
Nishant Sivakumar wrote: Initially I thought like that too. But the tech architect at our place helped change my mind. When writing MFC code I now follow the MFC style naming, but when writing .NET code, I try and follow .NET naming conventions as far as possible - though I still accidentally mix them up on occasions In the long run you'll see that it's probably better to stick to .NET conventions for your managed assemblies.
You haven't convinced me. I still prefer hungarian notation because it actually serves a purpose. I'll google it and see if I can find a tangible reason not to use it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|

|
Todd Smith wrote: 1) it adds uneeded noise
Opinion.
Todd Smith wrote: 2) you now have a type integrated into your variable name, which if you decide to change you will also need to update all references
Search.Replace (all files if necessary)
Todd Smith wrote: 3) it only make sense for some basic types (int, string, editbox, etc.) but you'll find in C# they only make up for a small percentage of your object types.
I've already said that. I only use it for intrinsic types.
Todd Smith wrote: btw here's a few coding styles for .NET
Blah, blah, blah.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
John Simmons / outlaw programmer wrote: Todd Smith wrote:
3) it only make sense for some basic types (int, string, editbox, etc.) but you'll find in C# they only make up for a small percentage of your object types.
I've already said that. I only use it for intrinsic types.
And for those it should be clear of which type they are by just reading the var name, without a prefix. Otherwise, in modern IDEs like vs you can just hover the variable and you see its type.
|
|
|
|

|
elektrowolf wrote: Otherwise, in modern IDEs like vs you can just hover the variable and you see its type.
Man, this is an OLD argument (not only did I concede the point, for the .Net purists, I now use naming conventions they expect). I still stand by my claim that you cannot assume that everyone will be using an IDE with some form of intellisense.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Hungarian notation can provide helpful information. If you come across a line of code like this...
err = fn();
From the variable name you can assume that err is some type of error information, but you need to either read through the code or use an IDE feature to track down what err is.
sErr = fn();
iErr = fn();
Is a vast improvement because it lets you know that the error information returned is a string or an integer error code.
My preference is to avoid Hungarian notation but incorporate such clues in the variable name e.g.
errMsg = fn();
errID = fn();
|
|
|
|

|
1- For string it doesn't matter as much (it's only a method call extra for ToString()) but for value types it safes you from boxing/unboxing (placing value types on the heap) which does costs a lot.
2- All the Microsoft .NET coding guide lines recommend against it, was just letting you know.
3- The "bad" thing about it is that your object is handled differently by the garbage collector because you defined a destructor.
4- Outside of the class
public namespace MyNamespace
{
public enum MyEnum { Value1, Value2, Value3 }
public class MyClass
{
public void TestMethod(MyEnum value)
{}
}
}
The big difference with enums in C# is that the values can have the same name.
enum Enum1 { Value1, Value2 }
enum Enum2 { Value2, Value3 }
Is perfectly legal and there is no confusion between Enum1.Value2 and Enum2.Value2, which iirc was a problem in C++.
For the record, I'm not criticizing you, just pointing out some differences between working with C++ and C#
|
|
|
|

|
Steve Hansen wrote: For the record, I'm not criticizing you, just pointing out some differences between working with C++ and C#
Yeah, I know. I was just asking the expected "why's".
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|

|
Regarding Hungarian Notation -- Joel Spolsky makes a good point that Hungarian Notation isn't bad, but has been misused : http://www.joelonsoftware.com/articles/Wrong.html
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
Parse a string with quoted elements, insert/add/delete elements, and is CLS compliant
| Type | Article |
| Licence | Public Domain |
| First Posted | 30 Jul 2007 |
| Views | 41,005 |
| Downloads | 163 |
| Bookmarked | 38 times |
|
|