|
This wasn't meant to be production level code, just a musing into the weird thought-processes of the original coder of this horror  !
0x3c0 wrote: And if you get an zero-length string?
Heavily depends upon the context, but IMO 0 is better as, the need to differentiate between null and "" when getting the length is rare (diffent for the object itself of course).
0x3c0 wrote: It's uncommon
Nope! string foo = ""; or string foo = string.Empty; Are the best ways to declare a string if you don't already have a value for it.
The last time I got into a discussion like this, it really dragged on....
http://www.codeproject.com/Messages/3251798/NULLABLE-type.aspx[^]
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
keefb wrote: Heavily depends upon the context, but IMO 0 is better as, the need to differentiate between null and "" when getting the length is rare (diffent for the object itself of course).
You're right; that requirement isn't common. But if I need it, I'd quite like to be able to get it without having to either write another method or altering the original method. It doesn't add much code, and it fits my personal coding style.
Plus, if the string is null, then retrieving Length will cause an exception. I don't like blurring cases together when one of them raises an exception.
|
|
|
|
|
I just made a throw-away observation that perhaps the orginal coder meant to perform some form of null checking and got it wrong (possibly by deleting it), then the error was repeated copied and pasted.
Personally I work hard to eradicate the nulls in the first place. I tend to check parameters for null when they are passed. Becuase I want code where nulls are the driven out, I beleive in handling null reference exceptions (such as the one that would occur on <string>string.length) as exceptions as a null value is an unexpected value (ie indicates a bug). Or at least I attempt this !
That said, if I had to, I'd wrap the <string>string.length as per my method. This has a few of benefits: developers don't have to worry about a special -1 value; No extra code is needed to handle the -1 value (null reference exceptions will, as described above) indicate a true bug ; the result can be displayed in a UI directly as end users would assume the -1 is a bug.
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
keefb wrote: Are the best ways to declare a string if you don't already have a value for it.
Of course that depends on the situation, but in general I disagree; I prefer null or uninitialized references.
As a particular situation: What I was working on today involves parsing some user input. For one of the parameters it's OK for the user to not specify a value (a default value will be provided later), but an empty value is not allowed. (It's possible that I'll allow an empty value in the future.) I initialize the variable to null and only assign a value if the user provided a non-empty value.
Another parameter is similar, but an empty value is allowed.
|
|
|
|
|
That's correct, I could not imagine why someone would do it like this.
|
|
|
|
|
Looking for a error in a project, I saw this code.
IFormatProvider culture = new System.Globalization.CultureInfo("en-US", true);
string year = itemDT["YEARBARRIER"].ToString();
string dateYear = "01" + "/" + "01" + "/" + year;
DateTime convertedDate = DateTime.Parse(dateYear, culture, System.Globalization.DateTimeStyles.AssumeLocal);
objBarrierFacade.YearBarrier = convertedDate;
That can be writed with only one line.
objBarrierFacade.YearBarrier = new DateTime((int)itemDT["YEARBARRIER"], 1, 1);
But I think that my solution is so easy and so obviuos to be used and other programmers need a good reason to spend more than a week in some easy use cases.
|
|
|
|
|
my rule of thumb is:
when some problem needs a lot of coding, there should be a shorter way to do it. Look for it!
Software library functionalities like .net's are based on the survey of the necessities of millions of developers.
This rule, as every one, has some exceptions.
Best regards,
Jaime.
|
|
|
|
|
Yeah, it's the objective of this post.
Some programmer use a lot of code because they don't know a easier way to do that.
|
|
|
|
|
Yes, kind of, give or take some input data checks.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Huh? How do you know there is input data involved here or that it's not known to be in a valid state?
|
|
|
|
|
The only comment I would make is that you have dropped the CultureInfo from your solution. Not sure how important that is for your project, but it could be significant. For example, under the Islamic calendar the current year is 1430. That would give a very different DateTime value than the Gregorian calendar used in the US.
|
|
|
|
|
I now that. But as you can see, the developer forced a CultureInfo to ensure a date format valid to parse his string. In the case explaned this is not necessary because the developer only need to create a datetime object instace from a int value representing a year.
|
|
|
|
|
...unless you run the code with a different default Culture, in which case you may get a different DateTime value for the same year input depending on the default calendar in use. The original code will always produce the same result since it specifies which CultureInfo to use. I'm not saying the original code is right, I am merely pointing out that strictly speaking your replacement code is not functionally equivalent to the original. Probably not an issue if your code will never run outside the US but, hey, I'm a geek and pedantry is part of the lifestyle.
|
|
|
|
|
My favorite coding horror isn't over the top, nor does it leave the system more vulnurable than it began. But how can I honestly trust anyone who does the following:
if(!!isLocked)
{
}
else
{
}
This wasn't a mistake on their part either. They used this kind of test in more than 50 places...
|
|
|
|
|
nathan.northcutt@gmail.com wrote: if(!!isLocked)
I wonder if it means DefinitelyNot()? 
|
|
|
|
|
c#5 will be shipping with this features
! => CertainlyNot()
!! => DefinitelyNot()
!!! => ReallyTrustMeItIsNot()
PS: still lying on the floor...
(yes|no|maybe)*
|
|
|
|
|
Add this to the list:
!!!! => ISwearByGodItIsNot()
|
|
|
|
|
This sounds to me like: it was evaluating for false and now is evaluation for true.
Best regards,
Jaime.
|
|
|
|
|
Definitely not! It means not not, does it not?
|
|
|
|
|
This does remind me of the admin authentication of a custom made e-shop I saw once.
The script checked whether the user name and admin matched, but there was no check whatsoever if this user was an admin. In other words, everyone with an account on the site could get in the admin panel 
Jeroen De Dauw
---
Forums ; Blog ; Wiki
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
it's cute!
maybe I should do that too!
Well maybe he did that just because he like the look of it and, anyway (!!b == b) is true (at least in C#, I guess it's not in C), so that's alright! 
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.
|
|
|
|
|
While I wouldn't generally use "!!" in the argument of an 'if' statement (which will inherently test whether the operand is non-zero) I see nothing wrong with using "!!" in certain contexts. For example, some compilers support bit variables and/or allow single-bit fields within a struct. If I need to set such variables based upon certain bits in a variable, I think it's cleaner to say bitVar = !!(byteVar & 0x40); than to say bitVar = ((byteVar & 0x40) != 0);. Basically, I regard "!!" as an operator which turns an integer into a Boolean. Anything wrong with that?
|
|
|
|
|
supercat9 wrote: Anything wrong with that?
Everything! It is not an operator in the sense of being part of the language. It is a clever trick that you may understand, but is likely to confuse someone who later has the job of maintaining the code. In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
|
|
|
|
|
Yay! 
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Richard MacCutchan wrote: In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
I use the more verbose syntax when testing more than one bit, to make explicit whether I am checking for any bit being set, or all bits being set. Whether or not anyone else uses the same convention, I find that at least in my own code it's nice to be able to distinguish at a glance between single-bit tests and multi-bit tests.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
