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
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