|
+1 for the enumeration. It brings a lot more room for expansion and it isn't a PITA in serialization or marshalling.
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
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
It could be good explanation if it wasn't around bool...and if wasn't around this specific code...
Did you see what the default value of the property (in BaseDefaultRequestOptions)? NULL...
But actually in the code (line 158) it turns to false...
Also the documentation states clearly that only true and false has meanings...
Such nullable bool has meaning in cases where you want to force the developer to make a choice, but in this code is a clear case of wasting CPU cycles...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The method at line 158 is called ApplyDefaultsAndClearEncryption, which is internal as well. true and false do have meaning, as well as leaving it undefined a.k.a. leave it to some setting to determine whether the value will be true or false.
I agree the code is unclear (as well as the documentation), but it does serve its purpose. How would you otherwise suggest to fall back to a default (which may either be true or false)?
|
|
|
|
|
Maarten Kools wrote: How would you otherwise suggest to fall back to a default (which may either be true or false)?
By deciding, what the default is! (it is decided to be false...)
The problem of this code (and it of course doesn't mean that nullable bool to be banned at all) is that, at the end of the road there is nothing about null value...It not used in any way to define a different behavior, but simply changed to false behavior...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
For now. It is extendable / patchable for future developements, which means that in version x+1.0 default may become true or there will be a mechanism to decide independently. It leaves a door opened to change - that's why I and other programmers would have used a enum, still having it nullable prevents errors, even when interfacing with different data sources.
Only the things that REALLY must exist or any reasoning is pointless should be non-nullable... unless you're developing a system which must be extremely picky about its inputs.
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
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
Of course it is impossible to future version to change default value (or behavior) - that will break applications in an instance...You not even ca nto introduce a new meaning for null, as it is today interpreted as false and changing that will also break applications...
If you are aiming to future options, you have to use enum, and add new values for new features...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
That's fine, if you bother to document what the null actually means.
Without that, its a bug waiting to happen.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: obviously the default for a bool (at the end of the day) will be false, if not stated otherwise...And if stated otherwise, than it should be part of the
IMO, this is the most significant statement in this thread.
The thing that drew me into this thread was its subject, which made me wonder how a bool could be considered nullable. When I see the word "nullable," I assume that the context is an object, rather than a primitive type such as bool, int, long, uint, ulong, double, etc.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
It means not set. It can trigger an auto-discover method, an error or a default behaviour.
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
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
Exactly...So the question remains...Why to use it in this code, where nothing happens and NULL interpreted as false...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
Which is there to aid cases of data bound control and required filed...but in the code above NULL simply interpreted as false and not as missing value...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
... discovered in a legacy app.
public string GetCode(string ProjectCode, string id)
{
try
{
int len = ProjectCode.Length + id.Length;
int rem = 10 - len;
switch (rem)
{
case 1:
ProjectCode = ProjectCode + "0" + id;
break;
case 2:
ProjectCode = ProjectCode + "00" + id;
break;
case 3:
ProjectCode = ProjectCode + "000" + id;
break;
case 4:
ProjectCode = ProjectCode + "0000" + id;
break;
case 5:
ProjectCode = ProjectCode + "00000" + id;
break;
case 6:
ProjectCode = ProjectCode + "000000" + id;
break;
}
}
catch (Exception ex)
{
}
return ProjectCode;
}
|
|
|
|
|
I have to compliment the author on writing bulletproof code - the catch all is awesome!
/ravi
|
|
|
|
|
"What? It errored? Where? I don't see any errors? I'm sure I covered/hid all the errors..." 
|
|
|
|
|
I had to go back and look. Yes, it's awesome, and about as enlightened as ignoring the return code of a method or function. Catch exception and throw it away. Why even bother with naming it?
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
ProjectCode should be camelCased, other than that I don't see what's wrong with it
|
|
|
|
|
Sander Rossel wrote: I don't see what's wrong with it
The only bit that's wrong is the stuff between the first and last bracket...
|
|
|
|
|
Is the original author still around? umm not that wou'd want to hunt him/her down and hurt them or anything.... 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
No, they left long ago. What confuses me the most is how you can know enough code to be able to write something like that, but not enough to know how to do it without the ridiculous switch statement. It's like a weird ignorance knife-edge.
|
|
|
|
|
Nothing like beautiful legacy code, very beautiful indeed.
|
|
|
|
|
The missing default handling and error handling (len >10) the mean exception handling shows me that some Visual Basic coder was on the loose. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
It's friggin C# code and you STILL have to bash VB?
Sounds to me like a C# dev who can't admit there are actually really very bad C# coders out there.
C# coders who are, if I dare say so, even worse than a lot of VB programmers out there 
And that comes, of course, from an ex-VB coder, who has seen crap code in both VB and C# (and both make you want to spoon your eyes out)
|
|
|
|
|
I'd post a legacy code snippet but I'd be sharing all the production connection strings they hardcoded at every single db connection. 
I seriously wished I could build a terminator to go back in time and shoot the coder in questions parents. 
|
|
|
|
|
Woah! I saw 'rem' and started reading it as a comment!
"Go forth into the source" - Neal Morse
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
