|
In case you want to overload it?
|
|
|
|
|
exactly, i find it very useful to create a Getter/Setter for each member (even if it is public) just in case something changes in the future and it needs to be recovered later.
Example:
if the length now has to adjust, for example, +5 in the current version, simply change the code on GetTranslation(...) { return object.translation+5; } and automatically all the code that refers to this translation is conveniently adjusted.
This is no coding horror, but a wise implementation with future alterability. 
|
|
|
|
|
PLEASE tell me you're joking!?!? 
|
|
|
|
|
This is bizzare and overwrought.
Perhaps he ment to do something like
protected int GetTransactionLength(string transaction)
{
if(transaction == null)
return 0;
return transaction.Length;
}
CCC solved so far: 2 (including a Hard One!)
|
|
|
|
|
And if you get an zero-length string? It's uncommon, but you might want to consider returning -1 instead of zero.
|
|
|
|
|
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!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
