Trojan Source and Python

Posted Nov 20, 2021 11:03 UTC (Sat) by kreijack (guest, #43513)
In reply to: Trojan Source and Python by ale2018
Parent article: Trojan Source and Python

> Microsoft Word used to have (or maybe still has, it's quite some time I don't use it)
> a macro language that was translated in the international editions. In Italian versions, if became se.
> Italian macros wouldn't run on English versions of Word, and vice-versa.
> Some companies reacted by requiring all branches install only original English versions of any Microsoft software.

:) Yes I remember how was hard writing the macro in Italian language....
I am happy to inform you that now the VBA macro is in English

> Does it make sense to use non-English words for identifiers and comments?

I would treat differently identifiers and comments:
Regarding the identifiers, my opinion is that it should be mandatory to write the identifiers in simple ascii (_a-zA-Z0-9). Preferably in English [*]. To be clear 'caffè' is (IMHO) unacceptable as identifier (however caffe, without accent makes my eyes bleed; so please never use caffe in an identifier)

For the comment, the compiler/language should allow any Unicode character. Instead the editor should warn if what is showed could be interpreted differently by the compiler (highlighting the omoglyphs and the bidirectional text outside the comment).

However I understood company that ask that the internal documentation (and so even the program source) must be written in English.

[*] When I use the term English, I am referring to a "very basic" technical English as the most common language. Let to me to say otherwise: using a very high level English for the comment, is a problem too.

Some programmers find it useful at times. For example, they say they can easily spot what parts of code where customized locally. I stopped doing so after I found Hebrew comments that I couldn't understand. In a globalized word, using non-English words hampers a program maintainability.

Non-English has to be used in strings, of course. However, such usage is normally relegated to a few special files. In that case, routinely running uniname -a on all imported software files looks like a practical precaution. Thanks to Jake for recalling that utility.