|
I get what you mean, users thinking by themselves are not good  , but I think design can solve those issues  :
Title:
Full Name:
Again, it works so well here that I'm still to find a place in .com.br domain that asks for a multi field name.
I don't there's magic bullet for anything, but I still believe that my argument stands, that single field names benefits outweighs multi-field names.
I think in US is more of a culture of "most do this way, so we're not changing", although I've seen several single field name cases already.
|
|
|
|
|
Yeah, while the forename-surname thing is kind of fair enough for many applications (most of us do work in English language countries), even in those, lots of people have more than one middle name.
|
|
|
|
|
|
I physically feel sick 
I may or may not be responsible for my own actions
|
|
|
|
|
AspDotNetDev wrote: Dim firstEmpty As String = String.IsNullOrEmpty(firstName)
String.IsNullOrEmpty returns "bool"... How are you assigning it to a string variable..? 
|
|
|
|
|
*grumbles* bloody VB *grumbles*
This is not the age of reason, this is the age of flummery, and the day of the devious approach. Reason’s gone into the backrooms where it works to devise means by which people can be induced to emote in the desired direction.
|
|
|
|
|
I had completely forgotten about Option Strict On; it's been years since I had the misfortune of writing in VB. Implicit conversions can be such a waste... At least it wasn't using loose variables.
|
|
|
|
|
Blame VB? That's hardly fair. Crap code can be written in any language. I believe the above is more a reflection of the coder, not the language.
|
|
|
|
|
Sure it's fair. VB didn't show a compilation error. It is happy enough to do implicit conversions that the programmer didn't intend.
Though, that can be turned off. Will have to remember to do that for all the VB projects at my company. I'm a little afraid of all the errors that will result.
This is not the age of reason, this is the age of flummery, and the day of the devious approach. Reason’s gone into the backrooms where it works to devise means by which people can be induced to emote in the desired direction.
|
|
|
|
|
I agree 100% that implicit conversions should not be allowed. If there was no way of disabling that then VB would suck, but since that can be controlled then I'm still not clear on why VB is to blame? That's like blaming a car for being in an accident because the brakes didn't self-engage... the tools are there, blaming VB for not knowing how to use them just doesn't make sense to me.
Besides - implicit conversion is not really the worst part of the function, is it?
|
|
|
|
|
G-Tek wrote: implicit conversion is not really the worst part of the function, is it?
That would get my vote for worst part. What part of the function would you vote worst part? Maybe we should suggest a Code Project survey. 
This is not the age of reason, this is the age of flummery, and the day of the devious approach. Reason’s gone into the backrooms where it works to devise means by which people can be induced to emote in the desired direction.
|
|
|
|
|
I guess as I look at it, why write 10 lines of code when you can write one? I understand that readability is always a factor, but there just seems to be a lot of code there for a simple function.
|
|
|
|
|
Dim firstEmpty As String = String.IsNullOrEmpty(firstName)
...
If firstEmpty Then
What's really horrible is that it's not only doing an unnecessary implicit conversion, it's converting it back implicitly with each "If" statement. That may not be a big performance hit here, but put this in an iteration for a few thousand/million loop cycles and I'm sure it would add up (unless maybe the compiler corrects for this mistake, I'm not certain).
That gets *my* vote...
|
|
|
|
|
G-Tek wrote: If there was no way of disabling that then VB would suck, but since that can be
controlled then I'm still not clear on why VB is to blame?
The problem for me is that VB defaults to bad practices, just to make things "easy". That is why I see it as a "beginner" language, and prefer C#, C++, etc. It's not just VB though, I personally despise the loose variables that I've had to use in the past with languages such as PHP.
No need to start a flame war over it, though. 
|
|
|
|
|
Maybe it would be ideal if they just forced everything to explicit (though I'm sure there would be a backlash from amateur developer who don't understand why so much of there code is suddenly broken). To be fair, I think the reason it is still in there as an option is for backward compatibility, keeping in mind VB has been around a long time.
You are absolutely right - it shouldn't default to bad practices. It's been a while since I created a new VB project so I'm not even sure if it defaults to implicit or not. I know that any VB projects we have are all explicit.
It gets way worse with VBA though - you have to declare "Option Explicit" in every new module. Heck, by default you're not even required to declare variables! How crazy scary is that?!
No flame wars  I just have a tendency to defend VB because I find most of the complaints I see around it have less to do with the tool and more to do with the "tool" (ie. in many cases, amateur developer) that is using it.
If we, as developers, choose to blame the tools we use for everything that goes wrong then we would have to likewise allow the people that use our applications to blame us, as the app developers, for everything that goes wrong in the app (and in my experience most of the issues are the user, not the app).
I think we generally agree, but you simply come down harder on VB and maybe I'm too hard on the developer?
That's my two cents!
|
|
|
|
|
Timothy CIAN wrote: String.IsNullOrEmpty returns "bool"... How are you assigning it to a string
variable..?
I was wondering the same thing - the line shouldn't compile (and doesn't, when I test it)!
|
|
|
|
|
AspDotNetDev wrote: I wasn't sure if I should put this in "Clever Code" or "Hall of Shame".
Hall of shame, definitely, specially considering that this line would do the same job:
Return String.Format("{0} {1} {2}", firstName, middleName, lastName).Replace(" ", " ").Trim()
Yes, it works even if firstName, middleName and/or lastName are null.
Edit: Forgot the Replace
|
|
|
|
|
Indeed, that may act very similar. However, here are two problems I see with that code:
- What if, for whatever reason, a user has two consecutive spaces in their first name? Given the variety of cultures, I wouldn't discount this.
- This version creates several extra and unnecessary strings.
- Unnecessary CPU time spent scanning the name parts (first/middle/last) for space to replace.
Still, with how compact it is, I'd say those are fine trade offs.
This is not the age of reason, this is the age of flummery, and the day of the devious approach. Reason’s gone into the backrooms where it works to devise means by which people can be induced to emote in the desired direction.
|
|
|
|
|
You missed the condition, that the middle name should be omitted if first or last is missing...
|
|
|
|
|
Nope, if a middle name is all you have to call somebody, then you might as well call them that.
Fixign now. | But who's fixing the fixign? |
|
|
|
|
|
What I meant was:
GetFullName(null, "middle", "last") => "last"
GetFullName("first", "middle", null) => "first"
isn't accomplished by your expression... but as well doesn't justify the code of horror in the OP
|
|
|
|
|
Actually, I am the OP and I didn't catch that. Take some 5's. 
Fixign now. | But who's fixing the fixign? |
|
|
|
|
|
wahaha this a "Hall of Shame" code indeed XD
|
|
|
|
|
Recently I encountered brand new look at standard boring indexable collections like arrays or lists in code I worked on. To be more precise, at ways we usually use to iterate them. We no longer need properties or functions like: Length, Size, Count. See how it goes (example demonstrating the idea):
int[] someArray = new int[] {};
for (int i = 0; ; i++)
{
try
{
int item = someArray[i];
}
catch(Exception e)
{
break;
}
}
Smell the power! Lenght, Count, Size, etc. They are obsolete now. We will iterate an indexable collection item by item until it crashes and that means our iteration is finished. That's what try/catch block was really intended for!
P.S. int[] was used for demonstration purposes. You can try it at home with any indexable collection you want (in .NET, for example, any collection implementing IList or IList<T> will do just fine).
|
|
|
|
|
VUnreal wrote: You can try it at home
Shouldn't that be 'don't try this at home, leave it to the trained professionals'?
The bearing of a child takes nine months, no matter
how many women are assigned.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
