|
Finally someone using TryParse correctly!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
RugbyLeague wrote: Would have been better
What do you think about this?
private long _remainder = long.parse(((long)0).ToString());
ProgramFOX
|
|
|
|
|
public void WriteCode(ICodeContext ctx)
{
throw new BrainNotFoundException();
}
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
Nice!
|
|
|
|
|
I would suggest the following:
private long _remainder = (long)int.parse((0).ToString());
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I got the same kind of code a few lines earlier!
Extract from the code I'm working on[^]
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
Never underestimate the idiocy of the programmer who came before you.
Otherwise, you'll always be surprised by how stupid they can be.
|
|
|
|
|
I will not underestimate it again!! ^^
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
Super Lloyd wrote: I will not underestimate it again OK, I fess up. I have been surprised by the stupid programmer before me when that programmer was me.
|
|
|
|
|
Haha.. I should be wary of that one too indeed!! ^^
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
I have a singleton data cache I'm working with.
I was testing whether or not the cache items were removing correctly from a consumer of the data.
I was checking via a different object in the debugger that would pull the object in question from the cache.
The problem: This different object creates the bloody cache item if it doesn't exist, but in the debugger it just looked like it wasn't deleting. My code was fine all along... The brain fart was in the debugging... Double
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Been there! Logging/tracing would have given you insight a bit quicker.
Wout
|
|
|
|
|
I was trying to save some time in the testing as a failure would have been really obvious to spot in test.
Figure that... You'd think I would know better after how many years of doing this.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
That's what unit tests are for, surely?
Debugger based testing is fundamentally limited by the lack of repeatability intrinsic in having a human poking around during the session, whereas automated tests to do the same thing should (if designed correctly) be absolutely repeatable.
As a bonus the tests stick around long after the debug session is ancient history. If someone breaks the code several years from now, the tests will start failing to alert you to that fact.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
When I first started in a Microsoft position, I asked why they were renaming procedures that were basically doing the same thing. It was their control method, the old procedures retained old behavior, the new code expected new behavior. After the new was promoted to production, the old was removed from SQL. If the lab started squaking, they knew they missed something.
Sure missed that on a later project. About 80% of the existing tests were failing because the sprocs were massively changed and no-one bothered to maintain the tests when they re-wrote the sprocs.
|
|
|
|
|
I think that's the most stupid code I refactored today!
But barely, and there is a lot more!
public XYZ()
{
_xyz = "0 , 0 , 0";
string[] parts = _xyz.Split(',');
Double.TryParse(parts[0], out x);
Double.TryParse(parts[1], out y);
Double.TryParse(parts[2], out z);
}
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
public void WriteCode(ICodeContent ctx)
{
throw new BrainNotFoundException();
}
Super Lloyd wrote: A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
Where the work stops. Right?
Bob Dole The internet is a great way to get on the net.
2.0.82.7292 SP6a
|
|
|
|
|
You nailed it!
Both remarks!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
Super Lloyd wrote: public XYZ() { _xyz = "0 , 0 , 0";... Looks like someone was planning on getting a string feed and forgot to feed the string or forgot to stop destroying the string.
So what did you do to refactor it? Change code to x=0;y=0;z=0;? And keep _xyz = "0 , 0 , 0";? Remove _xyz = "0 , 0 , 0"; and verify the split causes at least 3 parts? Add error checking on the tryparses? Remove XYZ and all references?
|
|
|
|
|
I got rid of the '_xyz' string, it was only used internally (in addition to x,y,z double) and parse every now and then, to get the value of 'x,y,z'
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
|
Ho... I'm learning new power pattern every day!!!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
I wrote this little workaround earlier this year. EF complains about an insert where ParentId is set, but allows me to set it with an update.
using (var scope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
{
if (newProject.ParentId != null)
{
int parentId = newProject.ParentId.Value;
newProject.ParentId = null;
_projectRepository.Insert(newProject);
newProject.ParentId = parentId;
_projectRepository.Update(newProject);
}
else
{
_projectRepository.Insert(newProject);
}
scope.Complete();
}
|
|
|
|
|
Assuming this is a SQL Server connection, I don't think you can lay this directly at SQL's door, but you might want to see if triggers are involved and see what they do on insert/update. Maybe the update trigger on the child will insert the parentID in the parent table if it doesn't exist?
No, that doesn't make sense, the update should fail with a foreign key constraint failure before it reaches the trigger.
So, when it complains, what is its complaint?
|
|
|
|
|
Something long winded about referential integrity.
|
|
|
|