4 ms·
A note on non-ascii in code: I thought of it as an abomination, until hitting test pattern descriptors. On a project targeted at a non English speaking devs wi
by makeitdouble 2y ago
A note on non-ascii in code: I thought of it as an abomination, until hitting test pattern descriptors.
On a project targeted at a non English speaking devs with a strong domain knowledge requirement, writing the test patterns (endless arrays of input -> expected output sequences, interspersed with adjustment code) in the native language saves an incredible amount of time and effort, in particular as we don't need to translate obscure notions into even more obscure English.
And that had very little downsides as it's not production running code, lining will still raise anything problematic, and and the whole thing is easier to get reviewed by non domain experts.
We could have made a translation layer to have the content in a spreadsheet and convert it to test code, but that's not any more stable than having unicode names straight into the code.
- nine_k 2y agoString constants / symbols is one domain, keywords and reserved characters, another. They should be checked for different things. E.g. spell-checking string constants as plain text if they look as plain text is helpful. Checking for non-ASCII quotes / dashes / other punctuation outside quoted strings, where they can only occur by mistake, is also helpful.
- makeitdouble 2y agoMy comment got mistakenly autocorrected (meant "linting" instead of "lining"), which is so on point given the subject. I agree, and think a decent linter can deal with these issues, and syntax highlighting as well. In particular these kind of rules tend to get complicated with many exceptions (down to specific folders needing dedicated rules), so doing it as lint and not at the language level gives a lot of freedom on where and how to apply the rules and raise warnings.