|
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.
|
|
|
|
|
Actually, I would use bitVar = ((byteVar & 0x40) == 0x40);.
Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
If I am testing multiple bits, I will either explicitly test for being unequal to zero, or being equal to a particular number (depending upon whether the requirement is that at least one bit be set, or that all bits be set). I do not like the syntax you seem to favor, since its normal semantic meaning requires that the same constant appear on both halves of the comparison operator; if the two halves get edited out of sync, the code will break.
|
|
|
|
|
I agree.
Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Luc Pattyn wrote: Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
I like named constants too, but many of the same issues remain. If I have a test:
if ((somevariable & SOMEIDENTIFIER) == SOMEIDENTIFIER) I have to worry about whether the two "SOMEIDENTIFIER"s are the same. If the identifiers are the same and the value gets changed (but remains a power of two) things will be fine, but if the code is copied/pasted and then modified to use a different identifier, an imperfect patch job could cause all sorts of problems.
|
|
|
|
|
I agree once more.
If SOMEIDENTIFIER has more than one bit set, it all depends on the intent of the snippet; a switch might even be in order then.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
