|
|
|
Then ~ does not join ints, it complements them; do you mean they passed a string with "~" as delimiter?
|
|
|
|
|
That's the impression I got.
He who makes a beast out of himself gets rid of the pain of being a man.
|
|
|
|
|
Does the language support lists?
|
|
|
|
|
VickyC# wrote: Does the language support lists?
It's C#.
|
|
|
|
|
OMG!!! all the way I have been thinking it is some good old FORTRAN or PASCAL !!!
|
|
|
|
|
string foobar(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);
string sXmlSelection = xml.SelectSingleNode("//xmlSelection").OuterXml;
sXmlSelection = foo(sXmlSelection);
string sXmlRestriction = xml.SelectSingleNode("//xmlRestriction").OuterXml;
sXmlRestriction = foo(sXmlRestriction);
...
return doc.OuterXml;
}
string foo(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);
string s = xml.SelectSingleNode(...).OuterXml;
s = bar(s);
...
return doc.OuterXml;
}
string bar(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);
return doc.OuterXml;
}
void main()
{
string xmlSelection = "<data><record opt='new'>";
xmlSelection += "<elem1>" + getElem() + </elem1>";
xmlSelection += "<elem2>" + getElem() + </elem2>";
xmlSelection += "<elem3>" + getElem() + </elem3>";
xmlSelection += "<elem4>" + getElem() + </elem4>";
xmlSelection += "</record></data>");
string xmlRestriction = "<data/>";
string xmlData = <data><xmlSelection>" + xmlSelection + "</xmlSelection>";
xmlData += "<xmlRestriction>" + xmlRestriction + "</xmlRestriction></data>";
foobar(xmlData);
}
I swear I've seen call stacks where eight methods are all calling one another with strings and returning strings, all of them working on xml, even though in most cases the only information used by the methods is the innertext of particular nodes. Every method parses the string to build an xml document, finds the real parameters to the method as text - never checking if nodes exist and thus ensuring a meaningless NullReferenceException in the event the poor person trying to use this "business logic" fails to pass the correct (and undocumented) xml to a method - then does some work such as selecting something from a database, stuffs the result into the xml document somewhere, and returns the OuterXml.
Apart from this leading to code that spends virtually all it's time parsing xml strings and rendering documents back to such strings it is also incredibly wasteful of memory. And when what could have been int arrays grow large it leads to additional problems because of large objects (the strings are of course continous in memory, making it harder for the garbage collector to move them around).
If anyone has any idea where this idea that string is the perfect data structure for absolutely anything comes from, I would love to know. I have never been able to understand it.
|
|
|
|
|
dojohansen wrote: string is the perfect data structure
Hellooo...! String theory! 
|
|
|
|
|
If anyone has any idea where this idea that string is the perfect data structure for absolutely anything comes from, I would love to know. I have never been able to understand it.
Strings are a reasonable data structure for information storage in many contexts. Many SQL-style databases, for example, have standard ways of reading and writing strings, but vary in how they handle binary data. It may be necessary to encode strings to ensure they don't contain any "funny" characters, but that's usually not too hard. The key is to avoid unnecessary packing and unpacking while data is being used internally.
|
|
|
|
|
supercat9 wrote: Strings are a reasonable data structure for information storage in many contexts.
I don't really agree much with that, BUT... if you look at the original message you'll see that none of your stated reasons apply here anyway!
There is no reason one should use strings and only strings within a C# business layer. If a method needs the caller to identify three entities, say a customer, a start date and an end date, and returns the set of orders placed by that customer between the two dates, it's rather better to have something like
public List<Order> GetOrders(Customer c, DateTime start, DateTime end)
public List<Order> GetOrders(int customerID, DateTime start, DateTime end)
than
public string GetOrders(string xmlData)
for reasons I hope are obvious.
It may be acceptable to have both (for use with a particular AJAX implementation for example, like the one we've made and which is the reason why it's become this way), but the string version should then be in a separate class and not contain any actual business logic. It would pick out the bits of information the business logic needs from the string, use the appropriate business logic to obtain the result, and (probably using some third bit of logic) create an xml representation of it to be written to the response stream.
The only nice thing about strings is that they are the most interoperable data type, certainly if sticking to the 7-bit ASCII set. That is an important benefit in many contexts, but it's no reason to go ahead and only use strings everywhere except the database!
|
|
|
|
|
I hate to admit it, but I've found code like that here from a previous developer. It's also in C#, but the delimiter is a newline. Maybe you have our old developer?
public string FormatBarContent(string foo1,
string foo2, string f003,
string foo14,
)
{
StringBuilder sb=new StringBuilder();
sb.Append(foo1);
sb.Append("\n");
sb.Append(foo2);
sb.Append("\n");
sb.Append(foo14);
return sb.ToString();
}
And some of the foo's have been converted from numbers to strings. The routine that gets this string immediately Split()'s it and parses the numbers back into numbers. None of the data ever needs to leave the current thread. Don't they know what a struct is?
-- T
|
|
|
|
|
I've been rewriting a system that was originally written in VBScript. Yes, that's 5000+ lines of VBScript with no white space, and no comments. That alone has had me crying for weeks/months, but this pushed me over the edge:
At one point in the application we generate documents, to do so we pass a piece of XML to a third party utility that does a Word Merge (or whatever kids are calling it these days). Rather than pass each piece of data as a separate element they are doing some of the formatting in the VBScript.
Instead of passing
<person>
<name>John Smith
<dob>1/1/1970
They are passing:
<person>John Smith {they insert a vbtab} 1/1/1970
I can't change the document template, so for now I have to reproduce this horrible code in .Net. I'm going to spend a few hours in the shower tonight crying and trying to scrub off that dirty feeling...
|
|
|
|
|
Ouch!
I Hate having a dependency system that takes data in a certain way. You have to continue using the "bad" code!
|
|
|
|
|
Find out who wrote the VBScript and let him clean your house!
This statement is false.
|
|
|
|
|
Do you get paid for the job?
|
|
|
|
|
Is there any other kind of job?
|
|
|
|
|
Do you work for nothing?
It is assumed that the majority of us work for a living and get paid for doing the work. This codeing justly deserves to be written up in the horrors forum.
|
|
|
|
|
Private Sub aLabel_AfterLabelEdit(Cancel As Integer, NewString As String)
'+++ VB/Rig Begin Push +++
Const VBRIG_PROC_ID_STRING = "+aLabel_AfterLabelEdit"
Dim VBRigErr As Long, VBRigErrMsg As String
If VBRig.Trap_TrapsEnabled Then
On Error GoTo aLabel_AfterLabelEdit_VBRigErr
End If
Call VBRig_Error(VBRIG_PUSH_PROC_STACK, 0, "", VBRIG_MODULE_ID_STRING, VBRIG_PROC_ID_STRING)
'+++ VB/Rig End +++
Cancel = True
'+++ VB/Rig Begin Pop +++
Call VBRig_Error(VBRIG_POP_PROC_STACK, 0, "", VBRIG_MODULE_ID_STRING, VBRIG_PROC_ID_STRING)
Exit Sub
|
|
|
|
|
0. Find the person who write this code.
1. Work out were they live.
2. Break into the home.
3. LEave a severed head in his head.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
It looks surprisingly similar to the code you posted two days ago under the heading "Where's Waldo".
|
|
|
|
|
Yes, only this one was even a bigger horror especially since it only has one line of code that does anything & it's not even something that could raise an error. It's positively lovely.
|
|
|
|
|
I've seen this error rig code before. Sage Software has a utility in their MAS500 SDK that you can run to add error handle to all functions and subs that generates code very similar to this. There is no way anyone is hand writing that much error handling for "Cancel = True".
|
|
|
|
|
Yeah, I think this was a plug in which added this mess to all new functions/subs. They've since stopped using it, but it's still as one fugly mug when you see it, especially in something like this. Were I given a free reign, I'd be all over the my delete button right now.
|
|
|
|
|
This is a horror indeed, but one thing puzzles me:
Wes Jones wrote:
On Error GoTo aLabel_AfterLabelEdit_VBRigErr
Does VB support "long jumps" or sth? I don't see a aLabel_AfterLabelEdit_VBRigErr anywhere...
Greetings - Jacek
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
