name.Length > 0

is probably pretty safe.

That only works if you’re concatenating the first and last name fields. Some people have no last name and thus would fail this validation if the system had fields for first and last name.

Any notable examples apart from young children and Michael Scott that one time?

I've been compiling a list of them:

You seem to have forgotten quite a few, like

Honestly I wish we could just abolish first and last name fields and replace them with a single free text name field since there's so many edge cases where first and last is an oversimplification that leads to errors. Unfortunately we have to interact with external systems that themselves insist on first and last name fields, and pushing it to the user to decide which is part of what name is wrong less often than string.split, so we're forced to become part of the problem.

I did this in the product where I work. We operate globally so having separate first and last name fields was making less sense. So I merged them into a singular full name field.

The first and only people to complain about that change were our product marketing team, because now they couldn’t “personalize” emails like `Hi <firstname>,`. I had the hardest time convincing them that while the concept of first and last names are common in the west, it is not a universal concept.

So as a compromise, we added a “Preferred Name” field where users can enter their first name or whatever name they prefer to be called. Still better than separate first and last name fields.

I tried this too, and a customer angrily asked why they can't sort their report alphabetically by last name. Sigh.

Just split the full name on the space char and take the last value as the last name. Oh wait, some people have multiple last names.

Split on the space and take everything after the first space as the last name. Oh wait, some people have multiple first names.

Merging names is a one-way door, you can't break them apart programmatically. Knowing this, I put a lot of thought into whether it was worth it to merge them.

It’s not just external systems. In many (most?) places, when sorting by name, you use the family names first, then the given names. So you can’t correctly sort by name unless you split the fields. Having a single field, in this case, is “an oversimplification that leads to errors”.

Right, but then you have to know which name is the family name, which really could be any of them.

I’m not sure what you’re trying to get at. The field containing the family name is the one labelled “family name”. You don’t have two fields both labelled “name”; there’s no ambiguity.

One field?

Like people have only one name... I like the Human Name from the FHIR standard: https://hl7.org/fhir/datatypes.html#HumanName

People can have many names (depending on usage and of "when", think about marriage) and even if each of those human names can handle multiple parts the "text" field is what you should use to represent the name in UIs.

I encourage people to go check the examples the standards gives, especially the Japanese and Scandinavian ones.

See point 40 and 32-36 on Falsehoods programmers believe about names[1]

[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

I know that this is trying to be helpful but the snark in this list detracts from the problem.

Whether it's healthy or not, programmers tend to love snark, and that snark has kept this list circulating and hopefully educating for a long time to this very day

What if my name is

Slim Shady?