|
CDP1802 wrote: Now the build ritual does not fail anymore and the unit test ritual also has been sucessfully completed. Bravo! Now you can go back to sleep and hold up your build reports with 100% sucessful unit tests when somebody asks.
Wouldn't that be NaN% successful? Or did they only comment out the code INSIDE the tests, not the tests themselves?
|
|
|
|
|
Exactly, they commented out everything inside the tests that could potentially fail, mostly the assertions. They did leave the parts which call methods, so that the tests still 'cover' much of the code.
And from the clouds a mighty voice spoke: "Smile and be happy, for it could come worse!"
And I smiled and was happy And it came worse.
|
|
|
|
|
That is just really sad.
The tests are worse than useless, they are misleading because it looks like you have good coverage and are passing all the tests.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
CDP1802 wrote: cargo cult The expression I was gonna use!
There seem to be no lack of cargo culting around agile sadly.
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
that is the default testing technique used by millions of programmers. unless you have good dedicated programmers who really care about their code this unit testing BS will not yield any fruit...and the catch is if you have good programmers then very rarely they would need unit tests as they will write it right the first time. I deal with such programmers everyday they add 5 items to a list then check if the list has 5 items as if there was some leak in CLR.
|
|
|
|
|
|
Another reason for NOT using "meaningful nulls". What I actually do for the sake of effortless, by the way. [a meaningful wink to the Nullable "?" class].
Greetings - Jacek
|
|
|
|
|
Stumbled across this gem today. http://pastebin.com/4Nx8yggU[^]
For preservation sake, here is a snippet, but you get the idea:
Public ReadOnly Property BatteryPercent()
Get
If SystemInformation.PowerStatus.BatteryLifePercent.ToString = "1" Then
Return "100%"
ElseIf SystemInformation.PowerStatus.BatteryLifePercent.ToString = "0.99" Then
Return "99%"
ElseIf SystemInformation.PowerStatus.BatteryLifePercent.ToString = "0.98" Then
Return "98%"
ElseIf SystemInformation.PowerStatus.BatteryLifePercent.ToString = "0.97" Then
Return "97%"
... etc
Wow is all I can say.
|
|
|
|
|
And well commented.
I think we can all appreciate the thoroughness of the approach.
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
The difference between an ostrich and the average voter is where they stick their heads.
|
|
|
|
|
Don't know what language this is, but I'm sure you could use the following to reduce the code length:
' ...
Return (SystemInformation.PowerStatus.BatteryLifePercent.ToString *100) & "%"
' . End of function.
|
|
|
|
|
There you go, thinking like a programmer again. Where's that going to get ya?
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
The difference between an ostrich and the average voter is where they stick their heads.
|
|
|
|
|
Actually, it's:
Return (SystemInformation.PowerStatus.BatteryLifePercent * 100).ToString() + "%"
You did the ToString before the multiplication. Note that this:
SystemInformation.PowerStatus.BatteryLifePercent.ToString("p")
...does create a percentage conversion, but since it has decimals and a space it is not equivalent.
|
|
|
|
|
I used & and not + as & can join a string and a number.
+ will only add two nunbers or attach two strings.
I would usually use CStr$() but as I was not to sure what language this was, used & as it's used in a number of languages.
|
|
|
|
|
The "+" operator does work here, it implicitly converts the number to a string and concatenates it to the other. But yes, the "&" operator is for concatenation explicitly.
However, in your example, my key point was that you used the "*" operator between a number and a string...
|
|
|
|
|
I don't know what language uses a * between two strings.
* is usually used to multiply two numbers. EG 123*4 = 492
+ is used to add two numbers. EG 123+4 = 127. 123+"4" = error
& is used to join two numbers, strings or a number and a string. EG 123 & 4 = "1234"
If a language returns 492 or "492" from 123*"4" then in my opinion the language needs an update.
The following Visual Basic 5 code:
Private Sub Form_Load()
Dim a As Integer
Dim b As String
a = 123
b = "4"
MsgBox a * b
End Sub
displays 492, but should display an error acording to other versions of Basic.
|
|
|
|
|
|
And found another similar bit of work (done in Perl, so may be 'leigt'?)
http://pastebin.com/TiyDDuPp[^]
for ($loopCount=0; $loopCount <= $stringLength; $loopCount++) {
$char = substr($inputString,$loopCount,1);
if ($char eq 'a') { $char = uc($char); }
elsif ($char eq 'b') { $char = uc($char); }
...
elsif ($char eq 'z') { $char = uc($char); }
else { $char = $char ; }
$outputString = $outputString . $char;
}
return $outputString;
|
|
|
|
|
It couldn't have been done with a generic approach, look at the last line:
Else
Return "NA"
That required a custom solution!
Just kidding
BTW, shouldn't that be 'N/A'?
'As programmers go, I'm fairly social. Which still means I'm a borderline sociopath by normal standards.' Jeff Atwood
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
Julien Villers wrote: BTW, shouldn't that be 'N/A'?
Na
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Julien Villers wrote: BTW, shouldn't that be 'N/A'?
Not when you have to scrape for every byte you can get.
I'm not a programmer but I play one at the office
|
|
|
|
|
NA is correct because if you can't determine the battery percentage you must be dealing with sodium
|
|
|
|
|
This is a good example for an uncertainty principle. Such method of retreiving a "battery percent" may indeed change the BatteryPercent itself...
Greetings - Jacek
|
|
|
|
|
This is pure genius, if he gets paid by the line that is.
If this method is ran while the battery is charging, is there a chance that it would return "NA" because the battery percentage changed at the correct moment?
Giraffes are not real.
|
|
|
|
|
Wow!
This is only not worse than what I've seen, because the DB field length related to what I found is small:
public string GetStringToDatabase(int value)
{
if (value > 99999999)
return "0" + value.ToString();
else if (value > 9999999)
return "00" + value.ToString();
else if (value > 999999)
return "000" + value.ToString();
.
.
.
}
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
I did something like this when I was programming in assembly language back in college. I was making a way to get a value out of a register out to the terminal in an integer form. Then, we only had 16 bit registers and could only output -32738 to 32737. But, there was no library routines to output to the terminal.
|
|
|
|