On 6-4-2024 14:55, Tim Düsterhus wrote:
Hi
On 4/5/24 23:32, Juliette Reinders Folmer wrote:
I also took the liberty to ask accessibility expert Nicolas Steenhout
[1] for his opinion on this topic and he has given me permission to
quote his reply:
> From a human readability and an accessibility perspective, Camel
Case
are best when words are concatenated like that.
> The rule I’d use here is uppercase the first letter of a word. Then
lowercase the others. Unless you are writing an acronym.
> So in your example, it should be `PerformHTTPRequest()`
> The underscore becomes a problem because if for some reason we’re
writing code as an example and it gets underline for any reason, the
underline gets lost
Thank you. I must admit I find it a little hard to interpret the
answer without also seeing the corresponding question, because the way
the question was phrased might've influenced the answer.
While I personally disagree with the acronym casing, it is not too bad
in the example identifier used ("Perform HTTP Request"). However the
naming policy will not just need to make the average case look great,
but also make the worst case look acceptable. If it cannot do so and
needs exceptions, then it failed to be a useful policy.
Hoping it isn't too much of a request, would you mind asking Nicolas
whether the answer changes, when facing the following extreme examples
consisting of consecutive acronyms.
I'm intentionally writing them in their natural casing with spaces to
hopefully not influence the response:
1.
PCG Oneseq 128 XSL RR 64
which for reference is "Permuted Congruential Generator One Sequence
128-Bit state XorShift Low Bits Random Rotation with 64-Bit Output",
with the abbreviations / acronyms matching the naming in the reference
implementation / corresponding paper.
2.
PDO ODBC
which is "PHP Data Object Open Database Connectivity", but no one
writes those acronyms out in full.
3.
XML HTTP Request
which is "eXtensible Markup Language HyperText Transfer Protocol
Request". I'd argue that the name is not really descriptive in the
first place, but it's another existing real-world example.
4.
UUID v4
Taken from Ben Ramsey’s UUID library:
https://github.com/ramsey/uuid/tree/4.x/src/Rfc4122
5.
S3 Client
as in "Amazon Simple Storage Service Client". Taken from Flysystem:
https://github.com/thephpleague/flysystem/blob/3.x/src/AwsS3V3/S3ClientStub.php
Best regards
Tim Düsterhus
Hi Tim,
I forwarded your questions from above verbatim to Nicolas and this was
his response (also quoted verbatim):
> So, this one is interesting.
> Sure, if you look at these extremes, stringing them back to back all
in a uppercase, they are not particularly user-friendly to read.
> Then again, none of these solutions are super user-friendly. We are
dealing with making the best of things.
> I have to say, it always gets my goat a little bit when people raise
“the extremes” in the context of accessibility. Somehow it always ends
up feeling like, to me at least, like a copout.
> Like, sure if you have someone who is blind, deaf, and paralyzed from
a stroke, making something accessible to them is going to be extremely
difficult. It doesn’t mean you shouldn’t make things accessible to
people who are blind, to people who are deaf, and to people who are
paralyzed from a stroke.
> This is a little bit like that. The solution I proposed earlier may
not work for everybody. But it will work for a majority.
Smile,
Juliette
