Pourquoi les langages de programmation non populaires utilisent un autre caractère pour délimiter les chaînes? [fermé]

StackOverflow https://stackoverflow.com/questions/965425

Question

Chaque langage de programmation que je sais (Perl, Javascript, PHP, Python, ASP, ActionScript, Commodore Basic) utilise des guillemets simples et doubles pour délimiter les chaînes .

Cela crée la situation continue de devoir aller à des longueurs grandes pour traiter correctement les citations, puisque la citation est très courante dans le contenu des chaînes.

Pourquoi les langages de programmation ne pas utiliser un autre caractère à délimiter les chaînes , qui ne soit pas utilisé dans une conversation normale \, | ou {} par exemple) afin que nous puissions EMBARQUER nos vies?

Est-ce vrai, ou suis-je sur quelque chose? Est-il un moyen facile d'arrêter d'utiliser des citations pour les chaînes dans un langage de programmation moderne?

Imprimer <<< FIN
Je sais ici document syntaxe, mais pour la manipulation de chaînes mineures, il est trop compliqué et il complique la mise en forme.
END;

[UPDATE] Beaucoup d'entre vous ont fait un bon point sur l'importance d'utiliser des caractères ASCII. J'ai mis à jour pour refléter les exemples que (le barre oblique inverse , le tuyau et accolades ).

Était-ce utile?

La solution

python a un type de chaîne supplémentaire, en utilisant des guillemets triples,

"""like this"""

En plus de cela, Perl vous permet d'utiliser tout délimiteur que vous voulez,

q^ like this ^

Je pense que pour la plupart, les délimiteurs de chaîne sont régulièrement utilisés parce qu'ils font sens. Une chaîne est entre guillemets doubles. En plus de cela, la plupart des développeurs sont habitués à utiliser leur sens commun en ce qui concerne les chaînes qui modifient radicalement la façon dont les chaînes sont présentées pourrait être une courbe d'apprentissage difficile.

Autres conseils

Perl vous permet d'utiliser vous aimez ce que les caractères

 "foo $bar" eq
 qq(foo $bar) eq
 qq[foo $bar] eq
 qq!foo $bar! eq
 qq#foo $bar# etc

Meanwhile
 'foo $bar' eq
 q(foo $bar) eq
 q[foo $bar] eq
 q!foo $bar! eq
 q#foo $bar# etc

La syntaxe étend à d'autres fonctions, y compris les expressions régulières, ce qui est pratique si vous avez affaire à URIs.

 "http://www.example.com/foo/bar/baz/" =~ /\/foo/[^\/]+\/baz\//;
 "http://www.example.com/foo/bar/baz/" =~ m!/foo/[^/]+/baz/!;

actuel: "Typewriter" Les marques 'citation'

Il y a beaucoup de bonnes raisons d'utiliser les guillemets que nous utilisons actuellement:

  • Citations sont faciles à trouver sur les claviers -. Ils sont faciles à saisir, et ils doivent être facile, car il faut cordes si souvent

  • Citations sont en ASCII - la plupart des outils de programmation ne gèrent bien ASCII. Vous pouvez utiliser ASCII dans presque tous les environnements imaginables. Et ce qui est important lorsque vous fixer votre programme sur une connexion telnet dans un serveur lointain lointain.

  • Citations sont disponibles dans de nombreuses versions - guillemets simples, guillemets doubles guillemets. Ainsi, une langue peut attribuer des significations différentes pour les chaînes entre guillemets différemment. Ces citations différentes peuvent également résoudre les "citations « à l'intérieur » citations de problème.

  • Citations sont naturels - anglais utilisé citations pour marquer les passages de texte bien avant les langages de programmation suivies. Guillemets linguistique sont utilisés exactement de la même manière que dans les langages de programmation. Les citations sont naturelles de la même manière + et - sont naturels pour l'addition et soustractions

  • .

Alternative: « typographiquement » « correct » cite

Techniquement, ils sont supérieurs. Un grand avantage est que vous pouvez facilement entre guillemets différencier ouverture et de fermeture. Mais ils sont difficiles à taper et ils ne sont pas en ASCII. (Je devais les mettre en un titre pour les rendre visibles dans cette police StackOverflow du tout.)

Si tout va bien un jour où ASCII est quelque chose que seuls les historiens se soucient et les claviers ont changé en quelque chose de totalement différent (si nous allons même avoir des claviers à tous), il y aura un langage de programmation qui utilise de meilleures citations ...

Python n'avoir un autre séparateur de chaîne avec la citation triple-double "" "ficelle" "".

Les guillemets simples et doubles guillemets sont utilisés dans la plupart des langues puisque c'est le délimiteur standard dans la plupart des langues écrites.

Langues (devrait) essayer d'être aussi simple à comprendre que possible, et en utilisant quelque chose de différent de guillemets pour traiter les chaînes compliquent inutilement.

En utilisant des guillemets pour définir un ensemble de caractères séparés du texte englobante est plus naturel pour nous, et donc plus facile à lire. En outre, "et" sont sur le clavier, tandis que les autres personnages que vous avez mentionnés ne sont pas, il est donc plus facile de taper. Il est possible d'utiliser un caractère qui est largement disponible sur les claviers, mais je ne peux pas penser à celui qui a gagné « t ont le même genre de problème.

E: J'ai raté le caractère pipe, ce qui peut effectivement être une alternative viable. Sauf qu'il est actuellement largement utilisé comme opérateur OR, et la question de la lisibilité est toujours valable.

Parce que ces autres caractères listés ne sont pas ASCII. Je ne suis pas sûr que nous sommes prêts pour, ou besoin d'un langage de programmation en unicode ...

EDIT: Pour ce qui est pourquoi ne pas utiliser {}, | ou \, bien que ces symboles ont tous significations déjà dans la plupart des langues. Imaginez C ou Perl avec deux significations différentes pour « { » et « } »!

| des moyens ou, et dans certaines langues concaténer des chaînes déjà. et comment vous \ n si \ était le délimiteur?

Au fond, je ne vois vraiment pas pourquoi cela est un problème. Est \ » vraiment difficile? Je veux dire, en C, il faut souvent utiliser \%, et \ et plusieurs autres personnages à deux caractères alors ... Meh.

Parce que personne n'a créé une langue à l'aide d'un autre personnage qui a obtenu populaire.

Je pense que c'est en grande partie parce que la demande de changement de caractère est tout simplement pas là, la plupart des programmeurs sont utilisés pour la citation standard et ne voient aucune raison impérieuse de changer le statu quo.

Comparez ce qui suit.

print "This is a simple string."
print "This \"is not\" a simple string."

print ¤This is a simple string.¤
print ¤This "is not" a simple string.¤

Personnellement, je ne me sens pas vraiment comme le deuxième est plus facile ou plus facile à lire.

Ah, si vous voulez l'ancienne FORTRAN, où vous souhaitez citer en comptant le nombre de caractères dans la chaîne et l'intégrer dans un format H, tels que: 13HHello, World!. Comme quelqu'un qui a fait quelques choses avec FORTRAN à l'époque où le nom de la langue était majuscules, des guillemets et leur échapper sont une bonne chose. (Par exemple, vous n'êtes pas déconné si vous êtes hors d'un dans votre nombre de caractères manuel.)

Sérieusement, il n'y a pas de solution idéale. Il sera toujours nécessaire, à un moment donné, d'avoir une chaîne contenant tout caractère citation que vous aimez. Pour des raisons pratiques, les délimiteurs devis doivent être sur le clavier et facilement accessibles, car ils sont très utilisés. La syntaxe de q@...@ de Perl échouera si une chaîne contient un exemple de chaque caractère possible. les constantes Hollerith de FORTRAN sont encore pires.

Vous dites « avoir à aller très loin pour traiter correctement les citations »; mais il est seulement dans la représentation du texte. Toutes les langues modernes traitent des chaînes comme des blocs binaires, de sorte qu'ils ne se soucient pas vraiment sur le contenu. Rappelez-vous que la représentation du texte est seulement un moyen simple pour le programmeur pour indiquer au système ce qu'il faut faire. Une fois que la chaîne est interné, il n'a pas de mal à gérer les guillemets.

Une bonne raison serait probablement que si c'est la seule chose que vous voulez améliorer une langue existante, vous ne créez pas vraiment une nouvelle langue.

Et si vous créez une nouvelle langue, de choisir le bon caractère pour les citations de chaîne est probablement moyen chemin sur la descente liste todo de choses à mettre en œuvre effectivement.

Vous seriez probablement mieux loti choisir un délimiteur qui existe sur tous les claviers communs et ensembles de représentation terminaux, de sorte que la plupart de ceux que vous suggérez sont juste à ...

Dans tous les cas, un mécanisme de cotation sera toujours nécessaire ... vous gagnez une réduction du nombre de fois que vous utilisez au citant le coût de rendre la langue plus difficile pour lire non-spécialiste.

Il est donc pas tout à fait clair que c'est une victoire, et puis il y a la force de l'habitude.

Ada n'utilise pas de guillemets pour les chaînes. Ce ne sont que des caractères, et ne doivent pas être échappé à l'intérieur des chaînes.

Je trouve très rare que le caractère guillemet est dans une chaîne de texte normal que je rentre dans un programme informatique. Quand il le fait, il est presque toujours parce que je passe cette chaîne à un interpréteur de commandes, et ont besoin d'intégrer une autre chaîne en elle.

J'imagine la principale aucune raison de ces autres caractères sont utilisés pour délimiteurs de chaîne est qu'ils ne sont pas dans le tableau de code ASCII 7 bits d'origine. Peut-être que ce n'est pas une bonne excuse ces jours-ci, mais dans un monde où la plupart des concepteurs de langue ont peur de renverser la syntaxe C insensément merdique, vous ne vont pas obtenir beaucoup de preneurs pour un choix séparateur de chaîne hors du commun.

Python vous permet de mélanger des guillemets simples et doubles pour mettre entre guillemets dans les chaînes.

print "Please welcome Mr Jim 'Beaner' Wilson."
>>> Please welcome Mr Jim 'Beaner' Wilson.

print 'Please welcome Mr Jim "Beaner" Wilson.'
>>> Please welcome Mr Jim "Beaner" Wilson

Vous pouvez également utiliser les triples guillemets mentionnées précédemment. Ceux-ci étendent également sur plusieurs lignes pour vous permettre de garder également d'avoir à imprimer les nouvelles lignes.

print """Please welcome Mr Jim "Beaner" Wilson."""
>>> Please welcome Mr Jim "Beaner" Wilson

Enfin, vous pouvez imprimer des chaînes de la même manière que tout le monde.

print "Please welcome Mr Jim \"Beaner\" Wilson."
>>> Please welcome Mr Jim "Beaner" Wilson
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top