|
Richard MacCutchan wrote: In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
I use the more verbose syntax when testing more than one bit, to make explicit whether I am checking for any bit being set, or all bits being set. Whether or not anyone else uses the same convention, I find that at least in my own code it's nice to be able to distinguish at a glance between single-bit tests and multi-bit tests.
|
|
|
|
|
Actually, I would use bitVar = ((byteVar & 0x40) == 0x40);.
Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
If I am testing multiple bits, I will either explicitly test for being unequal to zero, or being equal to a particular number (depending upon whether the requirement is that at least one bit be set, or that all bits be set). I do not like the syntax you seem to favor, since its normal semantic meaning requires that the same constant appear on both halves of the comparison operator; if the two halves get edited out of sync, the code will break.
|
|
|
|
|
I agree.
Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Luc Pattyn wrote: Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
I like named constants too, but many of the same issues remain. If I have a test:
if ((somevariable & SOMEIDENTIFIER) == SOMEIDENTIFIER) I have to worry about whether the two "SOMEIDENTIFIER"s are the same. If the identifiers are the same and the value gets changed (but remains a power of two) things will be fine, but if the code is copied/pasted and then modified to use a different identifier, an imperfect patch job could cause all sorts of problems.
|
|
|
|
|
I agree once more.
If SOMEIDENTIFIER has more than one bit set, it all depends on the intent of the snippet; a switch might even be in order then.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
I guess my main point is that I view testing for a single bit as being a different operation from testing a multi-bit expression numerically (a judgment colored perhaps by the existence of instructions on my favorite microcontrollers to perform such tests). Using an expressions like "!!(expr & BITMASK)" for the cases where BITMASK is a single bit makes clear that the code is supposed to look at a single bit, as opposed to numerically masking the expression and examining the result. The compiler will recognize the single-bit mask and generate code to exploit the bit-test instructions regardless of how the source code is written, but I like having a different way of expressing single-bit tests from multi-bit ones.
BTW, I sometimes use 'case' structures for the multi-bit case, though if all four cases of two bit flags are populated, I'll often use an if/else-if tree, depending on what sort of speed is required.
|
|
|
|
|
This could have resulted from a quick conversion of Assert() statements. The assert is a positive statement that explodes if not true. To covert them to execute a non-lethal action the quickest and perhaps safest approach is to just change to an if() throwing a NOT in front of the expreseion. New error handling code follows.
...not advocating this, just offering an explanation.
|
|
|
|
|
|
I asked a developer for code to create a specific XML document to save time.
Here is what he sent.
Needless to say, it didn't save me any time.
Dim XMLFile As StreamWriter = New StreamWriter(strAssetFile, False)
XMLFile.WriteLine("<Assets>")
XMLFile.WriteLine("<Encoding>")
XMLFile.WriteLine("<Profile Specifier=" + """" + "Standard1" + """" + ">")
XMLFile.WriteLine("</Profile>")
XMLFile.WriteLine("</Encoding>")
XMLFile.WriteLine("<Asset FilePath=" + """" + strUpDestinationFile + """" _
+ " AssetID=" + """" + Movieid.ToString + """" _
+ " CustomerID=" + """" + "1129" + """" _
+ " AssetName=" + """" + strFileName.Substring(0, strFileName.LastIndexOf(".")).Replace("_", " ") + """" _
+ " AssetDescription=" + """" + "Upolad" + """" _
+ " Category=" + """" + """" _
+ " FileNameToUse=" + """" + strFileName.Substring(0, strFileName.LastIndexOf(".")) + """" _
+ " Bytes=" + """" + (0).ToString + """" _
+ " Activate=" + """" + (1).ToString + """" _
+ " />")
XMLFile.WriteLine("</Assets>")
XMLFile.Close()
CreateAssetXML = strAssetFile
|
|
|
|
|
While I generally can't stand Visual Basic for much, it does certainly have some neat features for working with XML. You should send your developer a link to this article on MSDN[^].
Adam Maras | Software Developer
Microsoft Certified Professional Developer
|
|
|
|
|
Well, there are many horrors in that code.
The longest line can be shortened 50% by using String.Format()
Besides this, there is a high risk to produce a bad-formed XML if you have quotes, less-than or greater-than symbols inside your strings.
XmlTextWriter is the proper class to do xml serialization.
Best regards,
Jaime.
|
|
|
|
|
What feedback did you provide the developer...?
|
|
|
|
|
Try<br />
Dim d As Double = Math.Sqrt(number)<br />
Catch ex As Exception<br />
'do stuff<br />
End Try
|
|
|
|
|
Shenanigans! Nobody is that dumb.
Please... no.
|
|
|
|
|
It's almost like this one I saw a long time ago:
if (abs(num)!=num) ...
(this is a real one...)
|
|
|
|
|
jkruza wrote: (this is a real one...)
lol, i didnt make this up
|
|
|
|
|
Yeah, I believe you.
But it's so stupid, it's really hard to believe it's real. 
|
|
|
|
|
true that 
|
|
|
|
|
jkruza wrote: (this is a real one
As opposed to an imaginary 1?
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
Ah! I've been looking on how to do this for months!!!
Jeroen De Dauw
---
Forums ; Blog ; Wiki
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
In the original BASIC, the absolute value would be used, so no error.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
