Hi, having read your great contextual positioning explanation :clap:,
I wonder if it's feasible to kinda "kern" CamelCase such that the internal wordBoundaries are a bit less tight?
CamilCase in the first line already looks good, because the narrow i allowed the l to shift leftwards.
So an example of this idea is that in CamelCase too it's worth moving the l leftwards to allow more space between lC?
(You could think of this as pretending capital letters are wider than they physically are, at least on their left side.)
But that's still easy because l is narrow.
In general though, the capital letter on the right is wider than most lowercase, leaving less wiggle room, so I have no idea if this is feasible in monospace... In the extreme example WidwmWwideLetters, there is no room to move the mW anywhere.
(OTOH currently the spacing before/after a capital is tighter than average inside a word, which conceptually makes no sense, maybe can at least reduce that?)
(All the ThiniIce variants also already look great, with both the last/First letters being narrow — essentially because your contextual positioning was not aggressive enough to compensate :). But that's just accidental, unlikely in actual code.)
Motivation:
There is some (not enough) research suggesting CamelCase is slower to read than snake_case (but the effect is weaker for experts):
It sounds generally plausible (but not clear from evidence!) that recorgnizing the individual words is harder in CamelCase without spacing between words. So I wonder if a little bit of spacing between words can help?
But the proposed tweaks are way too subtle to predict any measurable effect based on above studies which compared to very_visible_full_width_underscores...
[To be clear I'm neither scientist nor typographer, just programmer.]
https://whatheco.de/2011/02/10/camelcase-vs-underscores-scientific-showdown/#comment-180 gives a great example that in Haskell space between words has critical meaning — function application — so making CamelCase look closer to "Camel Case" could be actively harmful!
See also other comments there how the "single token" feel of CamelCase makes "paragraphs" easier to read...
And as the 2nd study says "The results of this study might not necessarily apply to identifiers
embedded in source code. It is entirely possible that camelcased identifiers might act as a better gestalt element when embedded inside programming constructs."
Hi, having read your great contextual positioning explanation :clap:, I wonder if it's feasible to kinda "kern" CamelCase such that the internal wordBoundaries are a bit less tight?
CamilCasein the first line already looks good, because the narrowiallowed thelto shift leftwards. So an example of this idea is that inCamelCasetoo it's worth moving thelleftwards to allow more space betweenlC? (You could think of this as pretending capital letters are wider than they physically are, at least on their left side.)But that's still easy because
lis narrow. In general though, the capital letter on the right is wider than most lowercase, leaving less wiggle room, so I have no idea if this is feasible in monospace... In the extreme exampleWidwmWwideLetters, there is no room to move themWanywhere. (OTOH currently the spacing before/after a capital is tighter than average inside a word, which conceptually makes no sense, maybe can at least reduce that?)(All the
ThiniIcevariants also already look great, with both the last/First letters being narrow — essentially because your contextual positioning was not aggressive enough to compensate :). But that's just accidental, unlikely in actual code.)Motivation:
There is some (not enough) research suggesting
CamelCaseis slower to read thansnake_case(but the effect is weaker for experts):It sounds generally plausible (but not clear from evidence!) that recorgnizing the individual words is harder in CamelCase without spacing between words. So I wonder if a little bit of spacing between words can help? But the proposed tweaks are way too subtle to predict any measurable effect based on above studies which compared to very_visible_full_width_underscores... [To be clear I'm neither scientist nor typographer, just programmer.]
FWIW, I see from https://typedrawers.com/discussion/3190/kerning-of-lowercase-uppercase-pairs that proportional fonts designers do kern for CamelCase, though maybe for standard kerning goal of perceptually uniform spacing, while the goal I propose here is non-uniform feel to separate the words...
Against:
https://whatheco.de/2011/02/10/camelcase-vs-underscores-scientific-showdown/#comment-180 gives a great example that in Haskell space between words has critical meaning — function application — so making CamelCase look closer to "Camel Case" could be actively harmful! See also other comments there how the "single token" feel of CamelCase makes "paragraphs" easier to read... And as the 2nd study says "The results of this study might not necessarily apply to identifiers embedded in source code. It is entirely possible that camelcased identifiers might act as a better gestalt element when embedded inside programming constructs."
screenshot source
``` ||||||||||||||||||||||||||||||||||||||||| CamilCase WidimWwideLetters ThiiiIce CamelCase WidemWwideLetters ThiniIce CamwlCase WidwmWwideLetters ThimiIce lowercase widemwwideletters thiniice UPPERCASE WIDEMWWIDELETTERS THINIICE ```