Don't they know what an array is?
-
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.
-
OriginalGriff wrote:
Unless they are VB developers, obviously
Then they trump even Brad Pitt!!
Panic, Chaos, Destruction. My work here is done.
You are both horrible liars. Come on, we all know the standard programmer package involves a guy living in mom's basement at 20-something who plays World of Warcraft, goes to ren faires and hasn't touch a female pink part in 20 something years. The upgraded "I'll code for food" programmer has a wife, 2 kids, a mortgage and wishes he had gone into business school. For the premium package you get the choice of it being male or female, and the programmer is actually happy in the job. Most business do not opt for this upgrade.
-
You are both horrible liars. Come on, we all know the standard programmer package involves a guy living in mom's basement at 20-something who plays World of Warcraft, goes to ren faires and hasn't touch a female pink part in 20 something years. The upgraded "I'll code for food" programmer has a wife, 2 kids, a mortgage and wishes he had gone into business school. For the premium package you get the choice of it being male or female, and the programmer is actually happy in the job. Most business do not opt for this upgrade.
-
You are both horrible liars. Come on, we all know the standard programmer package involves a guy living in mom's basement at 20-something who plays World of Warcraft, goes to ren faires and hasn't touch a female pink part in 20 something years. The upgraded "I'll code for food" programmer has a wife, 2 kids, a mortgage and wishes he had gone into business school. For the premium package you get the choice of it being male or female, and the programmer is actually happy in the job. Most business do not opt for this upgrade.
Obviously, you are not a european software developer! (Or you are a VB developer...) ;P
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones "Rumour has it that if you play Microsoft CDs backwards you will hear Satanic messages.Worse still, is that if you play them forwards they will install Windows"
-
VickyC# wrote:
Does the language support lists?
It's C#.
-
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.
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);// ... do something to doc
// pick out some part of the doc that another function processes...
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);
// ... do something to doc
// pick out some part of the doc that another function processes...
string s = xml.SelectSingleNode(...).OuterXml;
s = bar(s);...
return doc.OuterXml;
}string bar(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);// ... do something to doc
return doc.OuterXml;
}void main()
{
string xmlSelection = "";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "");string xmlRestriction = "";
string xmlData = " + xmlSelection + "";
xmlData += "" + xmlRestriction + "";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. A
-
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);// ... do something to doc
// pick out some part of the doc that another function processes...
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);
// ... do something to doc
// pick out some part of the doc that another function processes...
string s = xml.SelectSingleNode(...).OuterXml;
s = bar(s);...
return doc.OuterXml;
}string bar(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);// ... do something to doc
return doc.OuterXml;
}void main()
{
string xmlSelection = "";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "");string xmlRestriction = "";
string xmlData = " + xmlSelection + "";
xmlData += "" + xmlRestriction + "";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. A
dojohansen wrote:
string is the perfect data structure
Hellooo...! String theory! :-D
-
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);// ... do something to doc
// pick out some part of the doc that another function processes...
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);
// ... do something to doc
// pick out some part of the doc that another function processes...
string s = xml.SelectSingleNode(...).OuterXml;
s = bar(s);...
return doc.OuterXml;
}string bar(string xml)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);// ... do something to doc
return doc.OuterXml;
}void main()
{
string xmlSelection = "";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "" + getElem() + ";
xmlSelection += "");string xmlRestriction = "";
string xmlData = " + xmlSelection + "";
xmlData += "" + xmlRestriction + "";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. A
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.
-
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 GetOrders(Customer c, DateTime start, DateTime end)
public List 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!
-
You are both horrible liars. Come on, we all know the standard programmer package involves a guy living in mom's basement at 20-something who plays World of Warcraft, goes to ren faires and hasn't touch a female pink part in 20 something years. The upgraded "I'll code for food" programmer has a wife, 2 kids, a mortgage and wishes he had gone into business school. For the premium package you get the choice of it being male or female, and the programmer is actually happy in the job. Most business do not opt for this upgrade.
-
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.
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);
// sb.Append("\n");
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
