Skip to main content
Software Engineering

Return to Question

Tweeted twitter.com/StackSoftEng/status/1489116458139402241
Removed from Network Questions by Thomas Owens♦
Question Protected by Thomas Owens♦
Became Hot Network Question
Removed Python 2, as I'm no longer sure it was true. It was a while ago.
Source Link
Michael Macha
Michael Macha
  • 396
  • 1
  • 2
  • 12

I frequently encounter recommendations to specifically keep to ASCII characters in field and function names in documentation, even though non-ASCII (modern Unicode) generally works perfectly. An example is the recent Python 3.10 documentation.

I've been a bad boy in the past and have successfully used non-ASCII characters in many projects, including in Java, C#, and Python 2 & 3. This started on personal projects maybe ten years ago. For most of my teams, this is generally beneficial, as we're not amateurs (everyone has some way of producing a λ, é, or a θ on their keyboard quickly, like a compose key or a switched keyboard layout) and it speeds communication on the team. I feel it's actually led to more readable code, not less.

What I'm led to wonder is whether there's a reason, substantiated in an actual project, for this rule; or if they're impulsively assuming that everyone is going to be copy-pasting those characters. Or, arguably worse, they're assuming that not all systems can handle basic Unicode in 2022; which I think has come down to the specific hardware we're working with and is typically a non-issue.

Can anyone cite any points in the past where non-UTF-8 has, objectively, caused a project to fail or hindered it in some way, and provide me with some context for this recommendation?

I frequently encounter recommendations to specifically keep to ASCII characters in field and function names in documentation, even though non-ASCII (modern Unicode) generally works perfectly. An example is the recent Python 3.10 documentation.

I've been a bad boy in the past and have successfully used non-ASCII characters in many projects, including in Java, C#, and Python 2 & 3. This started on personal projects maybe ten years ago. For most of my teams, this is generally beneficial, as we're not amateurs (everyone has some way of producing a λ, é, or a θ on their keyboard quickly, like a compose key or a switched keyboard layout) and it speeds communication on the team. I feel it's actually led to more readable code, not less.

What I'm led to wonder is whether there's a reason, substantiated in an actual project, for this rule; or if they're impulsively assuming that everyone is going to be copy-pasting those characters. Or, arguably worse, they're assuming that not all systems can handle basic Unicode in 2022; which I think has come down to the specific hardware we're working with and is typically a non-issue.

Can anyone cite any points in the past where non-UTF-8 has, objectively, caused a project to fail or hindered it in some way, and provide me with some context for this recommendation?

I frequently encounter recommendations to specifically keep to ASCII characters in field and function names in documentation, even though non-ASCII (modern Unicode) generally works perfectly. An example is the recent Python 3.10 documentation.

I've been a bad boy in the past and have successfully used non-ASCII characters in many projects, including in Java, C#, and Python 3. This started on personal projects maybe ten years ago. For most of my teams, this is generally beneficial, as we're not amateurs (everyone has some way of producing a λ, é, or a θ on their keyboard quickly, like a compose key or a switched keyboard layout) and it speeds communication on the team. I feel it's actually led to more readable code, not less.

What I'm led to wonder is whether there's a reason, substantiated in an actual project, for this rule; or if they're impulsively assuming that everyone is going to be copy-pasting those characters. Or, arguably worse, they're assuming that not all systems can handle basic Unicode in 2022; which I think has come down to the specific hardware we're working with and is typically a non-issue.

Can anyone cite any points in the past where non-UTF-8 has, objectively, caused a project to fail or hindered it in some way, and provide me with some context for this recommendation?

Source Link
Michael Macha
Michael Macha
  • 396
  • 1
  • 2
  • 12

Are there historical problems with non-ASCII identifier characters in code?

I frequently encounter recommendations to specifically keep to ASCII characters in field and function names in documentation, even though non-ASCII (modern Unicode) generally works perfectly. An example is the recent Python 3.10 documentation.

I've been a bad boy in the past and have successfully used non-ASCII characters in many projects, including in Java, C#, and Python 2 & 3. This started on personal projects maybe ten years ago. For most of my teams, this is generally beneficial, as we're not amateurs (everyone has some way of producing a λ, é, or a θ on their keyboard quickly, like a compose key or a switched keyboard layout) and it speeds communication on the team. I feel it's actually led to more readable code, not less.

What I'm led to wonder is whether there's a reason, substantiated in an actual project, for this rule; or if they're impulsively assuming that everyone is going to be copy-pasting those characters. Or, arguably worse, they're assuming that not all systems can handle basic Unicode in 2022; which I think has come down to the specific hardware we're working with and is typically a non-issue.

Can anyone cite any points in the past where non-UTF-8 has, objectively, caused a project to fail or hindered it in some way, and provide me with some context for this recommendation?