FUTURE POSTS
- Expertise in the age of AI, or: Matt's Claude'll handle this - about one day from now
- 15+ years of working with coding agents - 6 days from now
- Putting Claude up against our test suite - 8 days from now
- The GPU Is the New Bangalore - 10 days from now
- Learning to code, 1990s vs 2026 - 14 days from now
There are posts all the way to May 05, 2026
Comments
At first I thought it would be interpreted as if ( (copiedStream.Length > 1) * Giga)
But then I realized the compiler would give an error (about bools, ints and ifs).
And when I entered the above piece of code in VS, I was quite surprised about the actual error. :)
A VB programmer in a pass life, perhaps?
Hehe.. I actually spent 10 minutes staring at that snippet before realising what was wrong. :-)
Same as Martin :-) but takes 15 mins :-D
Also had to enter it in VS before I got it. Even then, had to double-check MSDN :D Learnt something new today!
If you take that long to spot the problem, you need to read some C# for dummies books.
Shodan, if you code in more than one language (I assume you've read C# for dummies, but not VB for morons, nor Haskell for idiots), it's not hard to use the wrong operator.
In that regard, C# is behind other modern languages for not having an exponentiation operator (which could just be an alias for Math.Pow), which is more useful for high-level development than XOR (and they could have used **, which doesn't clash with anything)
I'm going back to school. . . . -
Isn't this an ugly way to do things regardless - why calculate the value every time? Why not just use const int giga = 1000000000?
That's why I prefer the "1e9" notation.
Jason, the compiler optimizes away the calculation as it is a const value.
Two minutes of blankly staring at the snippet and finally the facepalm moment :)
Ha! I totally would have made that mistake. :-P
@Jason - readability
@Juan, the only problem with the '1e9' notation is that it produces a double. Ayende's constant was an int, so it would require an additional explicit cast. Not terrible, but it does end up messing with readability.
I prefer 1 << 30. It's quite clear (everybody knows 1 << 10 is kilobyte) and I find it clearer because you have 10 for each prefix (10 = kilo, 20 = mega, 30 = giga, etc. - easier for me than 3, 6, 9).
Write the unit tests first, idiots!
TDD in your ass!
@hazzik, You might consider reading: How to Win Friends & Influence People
Unless, of course, you're trying to influence us to consider you in a less than stellar way.
@hazzik
Testing only proves the presence of bugs not their absence.
+1 for @configurator.
@Diego, I believe ** would clash with pointer multiplication
@configurator minor nitpick, according to the variable name 'giga', the ( intended) value 1.000.000.000 is correct.
1 << 30 == 1 GB (GiB) == 1.073.741.824 bytes.
Just as kilo equals 1000. 1 KB (KiB) equals 1024 bytes.
// Ryan
@Ryan: I couldn't care less. When talking about file size it may be "correct" to consider a gigabyte as 1000000000 bytes, but it is standard to consider a gigabyte as 1073741824 bytes.
That's why I prefer "complex" consts to have the format of:
int const Kilo = 1000;
int const Mega = 1000 * Kilo;
int const Giga = 1000 * Mega;
@configurator tell that to drive manufacturers :)
They usually advertise the base 10 value
compreviews.about.com/.../ActualHDSizes.htm
// Ryan
@Ryan: Yes, I'm fully aware of that. Like I said, I just don't care. When I'm talking about Gigabytes, I don't care about a 7% difference; sure, I care if something is 100GB or 200GB, but I don't give a rat's ass about that third digit.
Diego, don't take this the wrong way, but if you code in several languages you still need to know them well enough not to make these kinds of mistakes. That being said, we all make mistakes - mine was probably posting a rude comment. I apologise for that.
Comment preview