|
Yes, first-time sacrifices only.
|
|
|
|
|
It's a normal practice that the company does...
they just find their own way to develop something interesting and land up into something weird...
Post it in some newspaper it is a sure shot horror....
syth.feana
|
|
|
|
|
Member 4487083 wrote: I'm working with some really bad code at the moment. There is some code which joins a load of values (integers) with '~', and then it passes it to a function. So it would be something like 1~5~12~3 etc. In the function it then splits this values on the '~' to get each value. It would be so much more readable, efficient, and less frangile if they had used an array. It amazes me how these people do their job. The other code in the project isn't much better either, actually the other problems are more difficult to fix. I hate blaming other peoples code, but I think that's what I will need to do.
You're right; that is completely retarded.
Sincerely Yours,
Brian Hart
|
|
|
|
|
Oh trust me, this code (may be in JSON format would help?) is MUCH better for passing stuff across the process border and through shared memory then defining all the data in structures in IDL file and implement custom COM marshaller. Then any single access to this data structure causes almost 1000 disk read operations (it reads TLB from DLL) - I had to debug it, and it is not fun.
Once again, if they use this ~ for passing data across the process border - I would not blame them - yes, I would use SafeArray instead, but still I would not blame these guys.
|
|
|
|
|
that's extending a quite a bit of credit, lol!
|
|
|
|
|
|
|
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 !!!
|
|
|
|
|
I feel your pain, and yet I suspect you feel only some of mine. In the project I am working on this would no doubt have been implemented as follows:
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.
|
|
|
|