|
Maybe not in the states, but in europe software developers are next only to film and pop stars in the "shagabillity" stakes! Unless they are VB developers, obviously.
</lie mode>
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"
|
|
|
|
|
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.
|
|
|
|
|
ragnaroknrol wrote: You are both horrible liars.
I think they are quite good at it!
|
|
|
|
|
Obviously, you are not a european software developer! (Or you are a VB developer...)
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"
|
|
|
|
|
lol
Regards,
Jason Pezzimenti.
If you liked the answer that I have provided, then please click the 'Good Answer' link on the bottom-right of this post. Thank you.
|
|
|
|
|
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!
|
|
|
|