Timeline for Are there historical problems with non-ASCII identifier characters in code?
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 30, 2022 at 13:29 | history | edited | gnasher729 | CC BY-SA 4.0 |
added 251 characters in body
|
Jan 30, 2022 at 12:36 | history | edited | gnasher729 | CC BY-SA 4.0 |
added 281 characters in body
|
Jan 30, 2022 at 2:54 | comment | added | Austin Hemmelgarn | @GregBurghardt Even ignoring invisible characters and RTL/LTR issues, there are other readability problems. A, Α, and A are three different characters, treated by compilers (that support Unicode properly) correctly, but are indistinguishable from each other in almost every font you could name, and thus you need to know which one is being used in each instance to understand code that mixes them properly. The same issue exists to varying degrees with many characters in the standard Latin alphabet (for example, H, Η, and Н, which even have different associated sounds in the languages using them). | |
Jan 29, 2022 at 23:29 | comment | added | Christophe | @GregBurghardt It's not just invisible characters: apparently it is possible to misuse mixed scripting (left to right and right to left alphabets) to construct invisible code made of visible characters: krebsonsecurity.com/2021/11/… | |
Jan 29, 2022 at 23:21 | comment | added | Michael Macha | I am in total agreement about practicality, and I didn't even think about doppelganger characters. My interests are generally for scientific notation and concise code. (Doppelgangers would be a very funny thing to include in a password, though...) | |
Jan 29, 2022 at 23:20 | comment | added | Michael Macha | @GregBurghardt If only! We'll return to that in another ten years. | |
Jan 29, 2022 at 22:16 | comment | added | Greg Burghardt | I really think compilers and language design should eliminate the issue with invisible characters. | |
Jan 29, 2022 at 21:32 | history | answered | gnasher729 | CC BY-SA 4.0 |