|
I will never complain about our code base again.
OK - that was a lie, but I'm tempted.
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
I don't think this code is doing what you think: it is not testing whether number is negative. No exception will be thrown because Math.Sqrt(n) returns NaN if n is negative. This is a valid Double value, and the code will drop out of the Try-Catch block without executing the line you have labelled 'do stuff. The only way this will get an exception is if the variable number is a String such as "XYZ". Math.Sqrt will cast a string such as "16" to a Double then take the square root of that, so as long as the String represents a numeric value it will work. Even "-16" will work because this will return NaN. But something such as "XYZ" will fail with an exception because this cannot be converted to a number and you will get an error.
Having said that, there are better ways to check whether a String is numeric.
|
|
|
|
|
You find this in the overlong validation routines...
function isNumeric(strString) {
var strValidChars = "0123456789";
var strChar;
var blnResult = true;
for (i = 0; i < strString.length && blnResult == true; i++) {
strChar = strString.charAt(i);
if (strValidChars.indexOf(strChar) == -1) {
blnResult = false;
}
}
return blnResult;
}
Developer, meet isNaN() , isNaN() meet developer.
|
|
|
|
|
Nice. Very useful with empty strings.
|
|
|
|
|
isNaD() would return true for sure.
Jeroen De Dauw
---
Forums ; Blog ; Wiki
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
But there's a functionality difference here, which might be deliberate. isNan handles decimal points and minus signs, the example function does not.
|
|
|
|
|
gkushner wrote: Developer, meet isNaN
Nope.
isNaN takes a float/double as an input, all it does is keep track of a mathematical mishap, such as taking the logarithm of a negative number.
It does not deal with a string that may or may not represent something that is considered a valid number (before you can apply isNaN, you have to try and parse the string to a number, and that is what the code is about)
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
Local announcement (Antwerp region): Lange Wapper? Neen!
|
|
|
|
|
Well, actually JavaScript will try to cast a string provided to isNaN as a float.
So, if you write isNaN("10"), js will process the expression as isNaN(parseFloat("10")).
However isNaN(parseInt("10")) gets the job done.
|
|
|
|
|
|
|
That is a great horror! Not only is it completely bloated and demonstrating the lack of understanding for weak typing and implicit conversion in JS, but it's also a horrifically inefficient implementation of a function parsing an integer. The naming convention is the icing on the cake.
At least this person wasn't trying to open a window on the server-side or accessing session on the client. Many asp.net programmers (in no small part due to Microsoft's tendency to present asp.net as if it was windows forms programming in introductory classes, I suspect) seem to not even understand any of the implications of a client-server model...
|
|
|
|
|
gkushner wrote:
var strChar;
I hate weak-typing.
Greetings - Jacek
|
|
|
|
|
Not the worst code I've seen, but it's bad. This is typical code worked on by multiple developers over time. The
class this is in has over 5000 lines of code. All of it looks like this.
DataTable dtShopOrder;
if(sSNInPK.ToLower()=="yes;")
dtShopOrder = new ERP().GetShopOrderDetails(txtSerialNum.Text);
else
dtShopOrder = new Operation().GetShopOrderDetails(txtSerialNum.Text);
if(dtShopOrder == null || dtShopOrder.Rows.Count <=0)
{
this.showMessage("Cannot find the serial number. Please contact your System Administrator.", MessageType.Warning);
return;
}
txtShopOrder.Text = dtShopOrder.Rows[0]["ShopOrder"].ToString();
txtAssembly.Text = dtShopOrder.Rows[0]["Assembly"].ToString();
txtRev.Text = dtShopOrder.Rows[0]["Revision"].ToString();
txtCUCode.Text = dtShopOrder.Rows[0]["CUCODE"].ToString();
txtCustomer.Text = dtShopOrder.Rows[0]["CUNAME"].ToString();
txtQty.Text = dtShopOrder.Rows[0]["Qty"].ToString();
strSubAsmWC = "";
try
{
if(dtShopOrder.Rows[0]["SubAsmWC"] != null)
{
strSubAsmWC = dtShopOrder.Rows[0]["SubAsmWC"].ToString();
}
}
catch
{
strSubAsmWC = "";
}
iCustOpNum = -1;
iMACOpNum = -1;
iMACCount = -1;
strCustLabel = "";
strMACAddress = "";
if(dtShopOrder.Rows[0]["iCustLabelOpNum"] != null)
{
try
{
iCustOpNum = int.Parse(dtShopOrder.Rows[0]["iCustLabelOpNum"].ToString());
}
catch
{
}
}
if(dtShopOrder.Rows[0]["iMacAddressOpNum"] != null)
{
try
{
iMACOpNum = int.Parse(dtShopOrder.Rows[0]["iMacAddressOpNum"].ToString());
}
catch
{
}
}
if(dtShopOrder.Rows[0]["iMacAddressCount"] != null)
{
try
{
iMACCount = int.Parse(dtShopOrder.Rows[0]["iMacAddressCount"].ToString());
}
catch
{
}
}
if(dtShopOrder.Rows[0]["CustLabel"] != null)
strCustLabel = dtShopOrder.Rows[0]["CustLabel"].ToString();
if(dtShopOrder.Rows[0]["MacAddress"] != null)
strMACAddress = dtShopOrder.Rows[0]["MacAddress"].ToString();
Found this in there also
if(slAppConfig[AppConfig.Keys.address_defect_wc.ToString()].ToString().IndexOf(lblWCKey.Text + ";",0)>=0
|| lblWCKey.Text == this.GetCutOffWC() || lblWCKey.Text == "MRBW")
{
this.EnableDefectEdits(true);
}
else
{
this.EnableDefectEdits(false);
}
Everything makes sense in someone's mind
modified on Thursday, October 8, 2009 6:40 PM
|
|
|
|
|
Looks like you maintain the same persons code I do!
I swear this guy has only heard of the string datatype. Everything is in strings, booleans "true", "false". And my favorite, arrays "1|12|34|56|".
|
|
|
|
|
GibbleCH wrote: arrays "1|12|34|56|"
Depends on the language. In VB6, you do not have array initializers. Loading a list by parsing a string can be a very compact way of presenting code. Not as fast as manually setting each array element, but it does make the code shorter and still readable.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
May not be a horror, but what a waste of space
private void appendBooleanField( boolean value, boolean lastField )
{
if ( value )
{
appendField( "y", lastField );
}
else
{
appendField( "n", lastField );
}
}
Why couldn't they replace the whole function with
appendField(value ? "y" : "n", lastField);
That reduces the line count by 10 (not counting the 7 lines of comment for the function), and removes the overhead of a function call.
And, the example above is repeated over and over in the code.
SS => Qualified in Submarines
"We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill
"Real programmers can write FORTRAN in any language". Unknown
|
|
|
|
|
This looks quiet obvious to C, C++, C#, JavaScript and Java programmers, but maybe not for others.
Are you refering to some specific implementation?
Best regards,
Jaime.
|
|
|
|
|
It was in Java, but I guess I was thinking of any C derived language.
SS => Qualified in Submarines
"We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill
"Real programmers can write FORTRAN in any language". Unknown
|
|
|
|
|
Your reply appears to imply that C# code should look obvious to people who don't know C#, or even C(++), Java, JavaScript, or quite a few others that have the ternary operator. Not to mention the fact that a semi-intelligent person who does not recognize this construct in C# at least should know, if maintaining the code, that the code *is* C# and be able to find out what it is.
I am not sure what kind of programmers you think C# code should be written for, but personally I think it would be a mistake to attempt making C# read like VB6 for the sake of accomodating maintenance by someone who in essence is a non-programmer.
I'd point out that the "overhead of a function (sic!) call" is academic - at best. The compiler may well decide to inline the code. And even if it did not, there are many cases where the microseconds (if that much) spent on pushing and popping the stack would simply make no difference whatsoever to the value of the program. To me, it is still a horror though - but because it demonstrates a lack of knowledge about the language on the part of the author more than anything else.
|
|
|
|
|
I've been doing code cleanup like that for about a month. i find it everywhere.
|
|
|
|
|
No, no, you want a Dictionary<bool,string> , then use appendField( booldic [ value ] , lastField);
|
|
|
|
|
value ? "y" : "n" personally I don't really like this structure. (unreadable)
|
|
|
|
|
Unreadable!? You may not be *used* to reading it, but don't mistake infamiliarity with anything intrinsic to the syntax. There are however some objective aspects of code: The more there is to read, the more work it is to read. The more complex the code, the more work it is. The ternary adds absolutely *no* complexity compared to a branch and is far more compact. So how can it possibly be anything but more readable?
If you know of some other alternative to the ternary, other than branching, please enlighten me.
|
|
|
|
|
don't be so upset. I just disagree with you, everybody is entitled to an opinion.
|
|
|
|
|
I'm not upset. I just found your comment ("I personally find.." with no substantiation whatsoever) stupid. I think you'll agree I'm entitled to that opinion.
|
|
|
|