|
I write often comment for my "future self" like "HACK", "TODO" 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
|
That reads like a Daily Affirmation with Stuart Smalley. Brilliant!
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
#region Note To Future Developer
#endregion
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
At my first job we had a senior developer who was very into OOP. Only problem is the code base was Microsoft C 5.1. The guy was building C code like it was C++ classes, few people could follow it. After he moved on to bigger and better things I got to debug some of his stuff and found a comment like
"We aren't supposed to free() the same pointer twice but since it doesn't hurt anything"
Coming from Mister High and Mighty "Your code better conform and produce no warnings." 
|
|
|
|
|
MarkTJohnson wrote: We aren't supposed to free() the same pointer twice but since it doesn't hurt anything
Oh my, that is a very dangerous assumption I've seen people make before.
//First
char* data = (char*)malloc(100 * sizeof *data);
free(data);
data = NULL;
free(data);
//Second
char* data = (char*)malloc(100 * sizeof *data);
free(data);
free(data);
First one isn't going to cause problems. Calling free on an allocated pointer de-allocates that memory. Calling free on a null pointer doesn't do anything. But calling free on a non-null, de-allocated pointer as in the second example de-allocates the memory again which has undefined behavior. Another process or thread could have allocated that memory before the 2nd de-allocation. Now you've invalidated memory another program was using.
modified 6-Mar-17 14:08pm.
|
|
|
|
|
Or if you deallocate, allocate to something else, and then deallocate the original pointer again.
Your new allocation has then been deallocated ... sometimes 
Don't you just love intermittent bugs?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
There are several rants on the functionality of mstest... Yes, it offers a little less than other unit test frameworks.
But there are geniuses using it. What about:
Assert.AreEqual(actual, expected, "Value is wrong: {0}, expected: {1}.", actual, expected);That guy always wrote a custom message showing both the actual and the expected value. Has he ever read the message of a failing test?
Let's try with int expected = 42; int actual = 7;. The message is:
Assert.AreEqual failed. Expected:<7>. Actual:<42>. Value is wrong: 7, expected: 42. See: another bug.
Strangely, intellisense shows the signature correctly:
Assert.AreEqual<int>(int expected, int actual, string message, params object[] parameters) (+17 overloads) Well, even mstest is better than some professionals. 
[Edit]
Strange that I need to explain further...
The mstest framework works here absolutely the way it is documented, without any bugs.
A potential source of confusion is the order of arguments to Assert.AreEqual - NUnit does it the other way round. But intellisense shows it correctly, so anyone looking at the screen when writing the test will see where "actual" and "expected" have to go.
For testing your tests, you are expected to show that your test can fail, aren't you? At that moment, you will see the failure message. And now you have another opportunity to see where actual and expected should go: even when you do not provide a custom message mstest will tell you "Assert.AreEqual failed. Expected:<7>. Actual:<42>.", if you provide a custom message that will be appended. And thus you'll see that you do not need to repeat actual and expected in your custom message.
What happened to CodeProject that I need to say that so explicitly?
[/Edit]
modified 23-Feb-17 3:05am.
|
|
|
|
|
It's what I like to call the Microsoft 85% Principle. Pretty much all of their products are worked upon until they're approximately 85% complete and working. After that, functionality it either left missing or broken. 
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
What about people testing the framework?
Assert.AreEqual(int.Parse("42"), 42);If that piece of code starts to fail you've got bigger problems than a failing unit test 
Just stick to testing your own code (and maybe some external code you expect to change) 
|
|
|
|
|
Worse is (and I'm not sure about NUnit) here, that .AreEqual uses obj.Equals for comparison by default. It has overloads for common value types, but in some cases can yield surprises.
Generally, I think many test frameworks suffer from featuritis. It is better to simply have an Assert() method, taking a single Boolean expression, than have the possibility of bugs or unexpected behaviour in the test framework.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Once upon a time, the concept of enumeration had not yet been invented. Instead, you had to use long lists of const definitions mapping some name to some int. So I found a colleague writing code like:
private int DecodeElementType(string elementName)
{
switch (elementName)
{
case "Blah": return 1;
case "Blub": return 2;
case "Hmpf": return 3;
case "Grml": return 4;
case "Tralala": return 5;
default: return 0;
}
}I asked him if he knew what an enum is, and how to use Enum.Parse / Enum.TryParse. He said he knew that. But his code is superior...
|
|
|
|
|
Sooooo, when I pass in TRalala to his code, it's still going to be superior. 
This space for rent
|
|
|
|
|
You're going to get 0, unless you mean "Tralala".
|
|
|
|
|
|
Please use some other display method. As an engineer, I am "expression-blind" 
(see Engineers are cold and dead inside)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Sudden Sun Death Syndrome (SSDS) is a very real concern which we should be raising awareness of. 156 billion suns die every year before they're just 1 billion years old.
While the military are doing their part, it simply isn't enough to make the amount of nukes needed to save those poor stars. - TWI2T3D (Reddit)
|
|
|
|
|
Bernhard Hiller wrote: He said he knew that.
If I were a betting man (and I am), I would wager my house that he did not know that.
Slogans aren't solutions.
|
|
|
|
|
Implicit enums are ever worse.
public enum Implicit
AA_0
BB_1
CC_2
DD_3
EE_4
GG_6
HH_22
II_7
LL_17
...
end enum
Guess what value did HH_22 have? And GG_6? BTW the numbers in the end are useful since this enum maps fixed alarm codes that come from a PLC. The only reason the code worked was because the same creator of this enum didn't use its values but used magic numbers all over the code.
Half a day hunting for a bug because alarm 31 never matched with '== XX_31'. XX_31 equalled 30.
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
Sounds like a case of the wrong tool for the job. Implicit enums are great for representing a fixed set of ideas/behavior (like flags) that isn't mapped to specific values. If you need a fixed set mapped to specific values use explicit enums
|
|
|
|
|
Precisely. Even if I'm used to always explicit the enums - mainly because I work with a system that has a lot of marshalling and communications between different paradigms so more often than not I end up having to fix those values sooner or later.
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
My guess, he didn't know. Self-tough programming. What so superior about coding manually. The point of using enumeration is to allow the compiler to check for potential human errors. Tell him to go back to school.
|
|
|
|
|
I'd guess he did learn to code in school. Meaning he had coding courses, learned nothing (as usual, because those courses invariable suck), and then assumed he would not need learn any further.
|
|
|
|
|
Whats the language that can use a string in a switch statement?
|
|
|
|
|
I think the snippet is in C#, which does allow that.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
