Austin Danger Powers
-
AspDotNetDev wrote:
Of course, there will be validation rules (e.g., last names cannot appear before first names). Happy now? :rolleyes:
No. In Bavaria, the "family name" (which is called the "last name" in English) comes first. Also Hungarians do it this way.
Then I'll add "Family Name" and "Given Name", and they will not have the same validation rules. :)
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 actually know two people with 5-letter initials (they each have double middle and double last names).
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.
AspDotNetDev wrote:
5-letter initials
In Spanish speaking Latin America (maybe all Spanish nations?) you have two last names - your father's first last name and your mother's first last name. When a woman marries, they add their husband's first last name on to their name (so my wife has five names, excluding the 'del' and 'de'). Our niece already has five names so when she marries she'll have six names!? You think this is strange but every time they ask for my surname they wait for me to say a second one and I have to explain to them I'm British and don't have a second one; they think I'm the crazy one!
-
*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.
-
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.
-
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?
-
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. :rolleyes:
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:
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. :cool:
-
I actually know two people with 5-letter initials (they each have double middle and double last names).
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 think it's very weird in some countries there is the culture of splitting First and Last names. Some web sites/places don't even have middle name field. I wonder why this is, here in Brazil it's always one field for the name only. Is there any need for splitting the names? I find it more confusing only. Worse for the websites that have only first and last names. Do I use: "Franco, Fábio dos Santos" or "dos Santos Franco, Fábio". Here everywhere, it's only one field for registering anywhere, field splitting were never missed.
-
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. :cool:
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 :-D 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!
-
Luc Pattyn wrote:
How about the code?
Ok, I'll construct the N-name control. The user can enter any number of name parts, and select (from a drop-down) the type each name part is. It will look a bit like this:
[First v] _________
[Middle v] _________
[Last v] _________
[Freak v] _________[Add Name Part]
Of course, there will be validation rules (e.g., last names cannot appear before first names). Happy now? :rolleyes:
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.
Hmmm. This looks to be a Power-ful example for making a case for compiler localization: if you want an executable for say Tagalog, just change your display language in VS and re-compile. The compiler would pull in different rules for name construction based on Phillipine conventions. Then voila! You have no need to re-write your logic.
-
I think it's very weird in some countries there is the culture of splitting First and Last names. Some web sites/places don't even have middle name field. I wonder why this is, here in Brazil it's always one field for the name only. Is there any need for splitting the names? I find it more confusing only. Worse for the websites that have only first and last names. Do I use: "Franco, Fábio dos Santos" or "dos Santos Franco, Fábio". Here everywhere, it's only one field for registering anywhere, field splitting were never missed.
It can be useful to split names. That way, companies can send you emails and address you by your first name (or given name, or whatever name part it is common to address people by in a given region). So, they can say "Dear Joe" rather than "Dear Joe Blo III". It is also useful to let the user know that all portions of the name must be entered. For example, if entering credit card details, it is a handy reminder to users to have first/last name so they know they must enter their whole name. While unfair to those with different naming conventions, first/middle/last is the standard for English websites (some add title and others, but the main thing is first/middle/last). It might be best if they allowed for a toggle, so you could switch between first/middle/last or just "full name".
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.
-
Private Function GetFullName(firstName As String, middleName As String, lastName As String) As String
' Variables. Dim fullName As String Dim firstEmpty As String = String.IsNullOrEmpty(firstName) Dim middleEmpty As String = String.IsNullOrEmpty(middleName) Dim lastEmpty As String = String.IsNullOrEmpty(lastName) ' Combine name parts into full name. If firstEmpty Then If middleEmpty Then ' Powers. fullName = lastName Else If lastEmpty Then ' Danger. fullName = middleName Else ' Powers (ignore middle name). fullName = lastName End If End If Else If lastEmpty Then ' Austin (ignore middle name). fullName = firstName Else If middleEmpty Then ' Austin Powers. fullName = String.Format("{0} {1}", firstName, lastName) Else ' Austin Danger Powers. fullName = String.Format("{0} {1} {2}", firstName, middleName, lastName) End If End If End If ' Return full name. Return fullNameEnd Function
I wasn't sure if I should put this in "Clever Code" or "Hall of Shame". :)
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.
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
-
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. :rolleyes:
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.
-
It can be useful to split names. That way, companies can send you emails and address you by your first name (or given name, or whatever name part it is common to address people by in a given region). So, they can say "Dear Joe" rather than "Dear Joe Blo III". It is also useful to let the user know that all portions of the name must be entered. For example, if entering credit card details, it is a handy reminder to users to have first/last name so they know they must enter their whole name. While unfair to those with different naming conventions, first/middle/last is the standard for English websites (some add title and others, but the main thing is first/middle/last). It might be best if they allowed for a toggle, so you could switch between first/middle/last or just "full name".
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.
AspDotNetDev wrote:
companies can send you emails and address you by your first name
someString.Split(' ')[0];
AspDotNetDev wrote:
let the user know that all portions of the name must be entered
lblName.Text = "Full Name:"
I know that name splitting has it's usefulness, like displaying in formats like "Last, First Name" the way the user wants, but I believe single field names benefits outweighs by far the benefits of multiple field names. Not only on the functional perspective, but also on development. It's much simpler to have only one column on the database to hold a name. A better solution would indeed be a toggle, but then, that adds overhead to development.
-
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. :rolleyes:
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.
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...
-
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.
-
AspDotNetDev wrote:
companies can send you emails and address you by your first name
someString.Split(' ')[0];
AspDotNetDev wrote:
let the user know that all portions of the name must be entered
lblName.Text = "Full Name:"
I know that name splitting has it's usefulness, like displaying in formats like "Last, First Name" the way the user wants, but I believe single field names benefits outweighs by far the benefits of multiple field names. Not only on the functional perspective, but also on development. It's much simpler to have only one column on the database to hold a name. A better solution would indeed be a toggle, but then, that adds overhead to development.
How would your code handle a user who enters: "Mr. Fabio Franco, Ph.D."? :) Or how about these:
- "Mr Fabio Franco, Phd"
- "Mr Fabio Franco the first, phd cna"
- "Mrs. Fabio Franco"
- "Fabio Franco, Mr"
- "Fabio Franco III"
- "Fabio"
There is quite a bit of variation out there, and I'm sure more variation I don't know about in other cultures. Users do funny things when you let them (try to) think for themselves.
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.
-
How would your code handle a user who enters: "Mr. Fabio Franco, Ph.D."? :) Or how about these:
- "Mr Fabio Franco, Phd"
- "Mr Fabio Franco the first, phd cna"
- "Mrs. Fabio Franco"
- "Fabio Franco, Mr"
- "Fabio Franco III"
- "Fabio"
There is quite a bit of variation out there, and I'm sure more variation I don't know about in other cultures. Users do funny things when you let them (try to) think for themselves.
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 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.
-
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
You missed the condition, that the middle name should be omitted if first or last is missing... :cool:
-
There is a small change in the specs, we now have two more optional (middle?) initials. Please adapt your code... :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.