<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Andreas Schneider wrote:<br>
</div>
<blockquote
cite="mid:74ec056051ce81061a513f8ac5ee750b@chemnitz.dyndns.aksdb.de"
type="cite">Am 2016-04-02 14:38, schrieb Graeme Geldenhuys:
<br>
<blockquote type="cite">On 2016-04-02 13:16, Santiago A. wrote:
<br>
<blockquote type="cite">similar should be done. You would need
to make compulsory a command in
<br>
source code to tell which code set is using.
<br>
</blockquote>
<br>
As a contract programmer I already struggle working on code
where
<br>
identifiers, Class names, methods, code comments etc are written
in
<br>
non-English [I fully agree its their right to do so, as it is
not
<br>
feasible to think everybody can speak or write English]. But
adding
<br>
different character sets to the mix will massively increase that
hurdle.
<br>
</blockquote>
<br>
I used to strictly oppose non-english code as well. A colleague
actually managed
<br>
to convince me that there are indeed reasons for "localized"
identifiers:
<br>
in some projects the customers (usually with some industrial
background) have pretty
<br>
specific wordings or use of the language. If developers now start
introducing
<br>
their own wording (due to translating back and forth) you
complicate the
<br>
communication and synchronization between business unit and
development team.
<br>
In such special cases I now "accept" said code style. (Although I
still don't
<br>
like it ;-))
<br>
<br>
</blockquote>
I think those gains will be limited in scope but the disadvantages
are too huge for the general users.<br>
Imagine relaxing this requirement, there will probably be new
codes/libraries using non-english identifiers and if they become
popular later, a lot of end users might be forced to use these
non-english libraries.<br>
<br>
e.g. if a hash library A uses a non-english identifier for a library
to honour the Thai name of the scholar who invented it.<br>
Then an encryption or communication library B uses this library A.<br>
If this library B later becomes popular or a standard, all end users
using B will need setup their development environment to support
non-english identifiers, although only one of the many hash
functions in A has non-english identifiers.<br>
<br>
I am chinese myself. I cannot even type a Thai identifier, I will
then have to copy and paste the identifier. I could also easily
confuse one Thai identifier from another one.<br>
Imagine if I write a library with Chinese identifiers, most users
won't able to tell apart 2 Chinese identifiers.<br>
e.g. <br>
procedure 賣; {means SELL}<br>
begin<br>
end;<br>
procedure 買; {means BUY}<br>
begin<br>
end;<br>
<br>
<img src="cid:part1.06090207.09040408@avidsoft.com.hk" alt=""><br>
Can use tell them apart easily? <br>
<br>
Dennis<br>
<blockquote
cite="mid:74ec056051ce81061a513f8ac5ee750b@chemnitz.dyndns.aksdb.de"
type="cite">_______________________________________________
<br>
Lazarus mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>