Removing leading zeros from negative string
-
Never ever use Parse if there is an TryParse method. thats best pratice and will alway be ;) ;) ;)
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Only when it's available. Or, if you want the Exception to be thrown. Why avoid the Exception if you're just going to throw your own anyway?
-
Only when it's available. Or, if you want the Exception to be thrown. Why avoid the Exception if you're just going to throw your own anyway?
PIEBALDconsult wrote:
Only when it's available.
thats what i said ;) (if the method is there...) Now why would you even consider raising/throwing an exception, thats just bad pratice. never use exception for you code-flow. An exception should only be thrown, when it truly is an exception, like if your transfer data over the net and the cord gets unplugged, thats an exception. Parsing data that is not correct, is not an exception. Lets say in this case, you want to parse -002 to -2, and the value begin parsed, turns out to be "-002$" then its not an exception, then the value ("you should know"), you want to parse is incorrect, handle it. thats to correct way, I believe. Furthermore, I believe the code engine will spin down for every exception it has to handle. Just a short comparison: for 1000 parsings Parse: 4078 milliseconds
Try Parse: 0 millisecondsI used this code to test:
Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < 1000; i++) { try { int demo = int.Parse("x"); } catch (Exception) {} } sw.Stop(); Debug.WriteLine("Parse: " + sw.ElapsedMilliseconds); sw.Reset(); sw.Start(); for (int i = 0; i < 1000; i++) { int demo; int.TryParse("x", out demo); } sw.Stop(); Debug.WriteLine("Try Parse: " + sw.ElapsedMilliseconds);
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
PIEBALDconsult wrote:
Only when it's available.
thats what i said ;) (if the method is there...) Now why would you even consider raising/throwing an exception, thats just bad pratice. never use exception for you code-flow. An exception should only be thrown, when it truly is an exception, like if your transfer data over the net and the cord gets unplugged, thats an exception. Parsing data that is not correct, is not an exception. Lets say in this case, you want to parse -002 to -2, and the value begin parsed, turns out to be "-002$" then its not an exception, then the value ("you should know"), you want to parse is incorrect, handle it. thats to correct way, I believe. Furthermore, I believe the code engine will spin down for every exception it has to handle. Just a short comparison: for 1000 parsings Parse: 4078 milliseconds
Try Parse: 0 millisecondsI used this code to test:
Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < 1000; i++) { try { int demo = int.Parse("x"); } catch (Exception) {} } sw.Stop(); Debug.WriteLine("Parse: " + sw.ElapsedMilliseconds); sw.Reset(); sw.Start(); for (int i = 0; i < 1000; i++) { int demo; int.TryParse("x", out demo); } sw.Stop(); Debug.WriteLine("Try Parse: " + sw.ElapsedMilliseconds);
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Paw Jershauge wrote:
thats just bad pratice
Only at the application level, not at the framework level.
-
PIEBALDconsult wrote:
Only when it's available.
thats what i said ;) (if the method is there...) Now why would you even consider raising/throwing an exception, thats just bad pratice. never use exception for you code-flow. An exception should only be thrown, when it truly is an exception, like if your transfer data over the net and the cord gets unplugged, thats an exception. Parsing data that is not correct, is not an exception. Lets say in this case, you want to parse -002 to -2, and the value begin parsed, turns out to be "-002$" then its not an exception, then the value ("you should know"), you want to parse is incorrect, handle it. thats to correct way, I believe. Furthermore, I believe the code engine will spin down for every exception it has to handle. Just a short comparison: for 1000 parsings Parse: 4078 milliseconds
Try Parse: 0 millisecondsI used this code to test:
Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < 1000; i++) { try { int demo = int.Parse("x"); } catch (Exception) {} } sw.Stop(); Debug.WriteLine("Parse: " + sw.ElapsedMilliseconds); sw.Reset(); sw.Start(); for (int i = 0; i < 1000; i++) { int demo; int.TryParse("x", out demo); } sw.Stop(); Debug.WriteLine("Try Parse: " + sw.ElapsedMilliseconds);
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Paw Jershauge wrote:
Try Parse: 0 milliseconds
You don't find that a little suspicious? I expect the whole for loop got optimized away, I've had that happen before. Try summing up the values and print the sum after the loop to ensure that it doesn't it doesn't get optimized.
Paw Jershauge wrote:
catch (Exception) {}
I certainly didn't suggest that.
Paw Jershauge wrote:
int.Parse("x");
That's just silly.
-
PIEBALDconsult wrote:
Only when it's available.
thats what i said ;) (if the method is there...) Now why would you even consider raising/throwing an exception, thats just bad pratice. never use exception for you code-flow. An exception should only be thrown, when it truly is an exception, like if your transfer data over the net and the cord gets unplugged, thats an exception. Parsing data that is not correct, is not an exception. Lets say in this case, you want to parse -002 to -2, and the value begin parsed, turns out to be "-002$" then its not an exception, then the value ("you should know"), you want to parse is incorrect, handle it. thats to correct way, I believe. Furthermore, I believe the code engine will spin down for every exception it has to handle. Just a short comparison: for 1000 parsings Parse: 4078 milliseconds
Try Parse: 0 millisecondsI used this code to test:
Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < 1000; i++) { try { int demo = int.Parse("x"); } catch (Exception) {} } sw.Stop(); Debug.WriteLine("Parse: " + sw.ElapsedMilliseconds); sw.Reset(); sw.Start(); for (int i = 0; i < 1000; i++) { int demo; int.TryParse("x", out demo); } sw.Stop(); Debug.WriteLine("Try Parse: " + sw.ElapsedMilliseconds);
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Parse: 16016 500000000 Try Parse: 15440 500000000 About a four percent saving, big deal, it's not about performance anyway.
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch() ;
int demo = 0 ;
sw.Start() ;
for ( int i = 0 ; i < 100000000 ; i++ )
{
demo += int.Parse ( args [ 0 ] ) ;
}sw.Stop() ;
System.Console.WriteLine ( "Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ;demo = 0 ;
sw.Reset() ;
sw.Start() ;for ( int i = 0 ; i < 100000000 ; i++ )
{
int temp ;
int.TryParse ( args [ 0 ] , out temp ) ;
demo += temp ;
}sw.Stop() ;
System.Console.WriteLine ( "Try Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ; -
Paw Jershauge wrote:
thats just bad pratice
Only at the application level, not at the framework level.
Also on framework level, Microsoft contradicts its self sometimes in the framework, but hey I dont always follow my own guidelines either. - If you know the Error, of why the code fails, handle it. - Only handle exceptions you can recover from. - If you dont know why the exception was thrown, its better to let the framework kill your app. According to microsoft. But then again others think you should clean up what you can, and then exiting the orderly fashion.
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
Paw Jershauge wrote:
Try Parse: 0 milliseconds
You don't find that a little suspicious? I expect the whole for loop got optimized away, I've had that happen before. Try summing up the values and print the sum after the loop to ensure that it doesn't it doesn't get optimized.
Paw Jershauge wrote:
catch (Exception) {}
I certainly didn't suggest that.
Paw Jershauge wrote:
int.Parse("x");
That's just silly.
PIEBALDconsult wrote:
You don't find that a little suspicious? I expect the whole for loop got optimized away, I've had that happen before. Try summing up the values and print the sum after the loop to ensure that it doesn't it doesn't get optimized.
Actualy you might be right about the optimizing, but the fact is that the code is an will be faster running TryParse.
PIEBALDconsult wrote:
Paw Jershauge wrote: catch (Exception) {} I certainly didn't suggest that.
i didn't say you did. this was only a very very short demo test.
PIEBALDconsult wrote:
Paw Jershauge wrote: int.Parse("x"); That's just silly.
No not really, as my p.o.i. was to fail anyway.
Stopwatch sw = new Stopwatch(); int ParseOutPut = 0; sw.Start(); for (int i = 0; i < 1000; i++) { try { int demo = 0; if(i % 3 == 0) demo = int.Parse("x"); else demo = int.Parse("1" + i.ToString()); ParseOutPut += demo; } catch (Exception) { } } sw.Stop(); Debug.WriteLine("Parse \[" + ParseOutPut + "\]: " + sw.ElapsedMilliseconds); sw.Reset(); int TryParseOutPut = 0; sw.Start(); for (int i = 0; i < 1000; i++) { int demo; if(i % 3 == 0) int.TryParse("x", out demo); else int.TryParse("1" + i.ToString(), out demo); TryParseOutPut += demo; } sw.Stop(); Debug.WriteLine("Try Parse \[" + TryParseOutPut + "\]: " + sw.ElapsedMilliseconds);
Returns on my computer: Parse [938727]: 1464 ms Try Parse [938727]: 0 ms
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
Parse: 16016 500000000 Try Parse: 15440 500000000 About a four percent saving, big deal, it's not about performance anyway.
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch() ;
int demo = 0 ;
sw.Start() ;
for ( int i = 0 ; i < 100000000 ; i++ )
{
demo += int.Parse ( args [ 0 ] ) ;
}sw.Stop() ;
System.Console.WriteLine ( "Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ;demo = 0 ;
sw.Reset() ;
sw.Start() ;for ( int i = 0 ; i < 100000000 ; i++ )
{
int temp ;
int.TryParse ( args [ 0 ] , out temp ) ;
demo += temp ;
}sw.Stop() ;
System.Console.WriteLine ( "Try Parse: {0} {1}" , sw.ElapsedMilliseconds , demo ) ;Its all about performance, your code here assumes that everything is ok. so its not valid test.
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
Its all about performance, your code here assumes that everything is ok. so its not valid test.
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
If it fails, I want to throw and terminate.
-
Also on framework level, Microsoft contradicts its self sometimes in the framework, but hey I dont always follow my own guidelines either. - If you know the Error, of why the code fails, handle it. - Only handle exceptions you can recover from. - If you dont know why the exception was thrown, its better to let the framework kill your app. According to microsoft. But then again others think you should clean up what you can, and then exiting the orderly fashion.
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Paw Jershauge wrote:
why the code fails, handle it.
Some times you want to handle it by exiting.
Paw Jershauge wrote:
you can recover from
Correct.
Paw Jershauge wrote:
its better to let the framework kill your app
Yes, quite often, but that's up to the application, not any underlying code. But keep in mind that I write mostly console/batch programs and Windows Services.