Pourquoi C # est-il sensible à la casse? [fermé]

Question

Quel est le raisonnement derrière la prise en compte de la casse C #?

J'envisage de passer de VB.NET à certaines fonctionnalités du langage (RCC et rendement) et la compréhension du raisonnement derrière cette différence peut faciliter la transition.

[MISE À JOUR] Eh bien j'ai plongé il y a trois jours. Apprendre le C # n’a pas été particulièrement difficile, mais je me souvenais à peine de mes années de C ++ à la fin des années 90.

La sensibilité à la casse m'énerve-t-elle? pas autant que je le pensais ... En plus, je trouve que c'est réellement avantageux. En fait, je suis vraiment satisfait du CCR en tant que modèle de programmation de coordination asynchrone. Si seulement j'avais plus de temps sur le projet actuel, je mettrais la base de code en C # pour en tirer le meilleur parti. Ce ne serait pas juste pour mon client.

J'évalue mon projet actuel et je vois des threads bloquants PARTOUT! Ahhhh !!!

[UPDATE]

Eh bien, je programme en C # depuis près d’un an maintenant. J'apprécie vraiment la langue et je déteste VRAIMENT vraiment passer à VB (surtout quand c'est inévitable!)

Et le problème de la sensibilité à la casse? même pas un problème

Answer 1

C # est sensible à la casse car il prend la suite des langages de style C qui sont tous sensibles à la casse. C’est de mémoire que voici un lien MSDN qui ne fonctionne pas correctement pour moi maintenant je ne peux pas vérifier.

Je voudrais également souligner qu'il s'agit d'un cas d'utilisation très valable:

public class Child
{
   private Person parent;
   public Person Parent
   {
      get { return parent;}
   }
}

Oui, vous pouvez contourner cela en utilisant des préfixes sur vos variables membres, mais certaines personnes n'aiment pas le faire.

Answer 2

Ils pensaient probablement & «Nous ne voulons pas que les gens utilisent SoMeVaRiAbLe à un endroit et SOEVARIABLE à un autre.

Answer 3

Je pense que le fait qu'une affaire puisse transmettre des informations est une très bonne raison. Par exemple, par convention, les noms de classe, les méthodes publiques et les propriétés commencent par une lettre majuscule par convention. Et inversement, les champs et les variables locales commencent par une lettre minuscule.

Après avoir utilisé la langue pendant des années, le code est beaucoup plus facile à lire lorsque vous pouvez lire des informations simplement à partir du style des mots.

Et c'est pourquoi les gens le font parfois, et cela peut avoir un sens:

Foo foo = new Foo();

Je le fais tout le temps, c'est très utile. Si vous y réfléchissez dans une situation plus utile, comme celle-ci:

Image image = Image.LoadFrom(path);

Parfois, il est parfois logique d'appeler l'instance la même chose que le nom de la classe, et le seul moyen de les distinguer est le boîtier. En C ++, la sensibilité à la casse devient encore plus utile, mais c'est une autre histoire. Je peux élaborer si vous êtes intéressé.

Answer 4

Considérons les noms de variable dans le pseudocode suivant:

class Foo extends Object { ... }
...
foo = new Foo();

La sensibilité à la casse permet aux conventions qui utilisent la casse de séparer les noms de classe et les instances; de telles conventions ne sont pas du tout rares dans le monde du développement.

Answer 5

C # hérite de la sensibilité à la casse de C et de Java, qu'il essaie d'imiter pour faciliter le passage des développeurs à C #

Il y avait peut-être de bonnes raisons de rendre le cas C sensible au cas où il avait été créé il y a trois décennies, mais rien ne semble expliquer pourquoi. Jeff Atwood a écrit un bon article en faveur de cette la sensibilité à la casse n'a peut-être plus de sens . .

Answer 6

Je pense qu'avoir des identifiants sensibles à la casse peut rendre le code plus lisible, grâce à l'utilisation de conventions de dénomination. Bien, et même sans conventions de dénomination, la cohérence imposée par la sensibilité à la casse garantit que la même entité est toujours écrite de la même manière.

Answer 7

Probablement copié à partir de C, C ++, Java, etc. ou peut être conservé à dessein de manière à rester similaire à celui des autres langues.

Answer 8

C’était juste une question de goût dans l’équipe de créateurs de langages C #. Je suis prêt à parier que c'était pour la langue commune avec d'autres langues de la famille C. Cela conduit toutefois à certaines mauvaises pratiques de programmation, telles que le domaine privé et sa propriété associée, qui ne diffèrent que dans le cas de la première lettre.

EDIT:

Pourquoi cela pourrait-il être considéré comme mauvais?

class SomeClass 
{
    private int someField;

    public int SomeField
    {
        get { return SomeField; } 
        // now we have recursion where its not wanted and its 
        // difficult for the eye to pick out and results in a
        // StackOverflowException.
    }
}

Le préfixage des champs privés avec un _ ou un m peut être plus facile à repérer. Ce n'est pas un gros problème et personnellement, je vais faire exactement ce que je viens de dire, c'est mauvais (alors poursuivez-moi en justice!).

Answer 9

L'analyse est également un peu plus facile pour les langages sensibles à la casse. Tant qu'il n'y a pas de bonne raison de choisir la méthode non sensible à la casse, pourquoi s'en préoccuper?

Answer 10

Vous envisagez cela de manière très limitée - de votre point de vue. Les concepteurs de langues doivent prendre en compte tout un ensemble de considérations: raisons culturelles, compatibilité avec d'autres langues, pratiques de codage courantes, etc.

Toutes les langues modernes utilisent le respect de la casse: lesquelles ne le font pas?

En tant que personne ayant utilisé BASIC pendant un certain nombre d’années, j’étais fatiguée de voir les développeurs utiliser différents cas pour la même variable. Ce genre de chose est très fastidieux à regarder et encourage une programmation négligée. Si vous ne pouvez pas être dérangé pour faire la bonne affaire - quoi d'autre ne peut pas être dérangé à faire?

Answer 11

De Guide du développeur .NET Framework Conventions de capitalisation , respect de la casse:

  

Les directives de capitalisation existent   uniquement pour faciliter l'identification des identifiants   lire et reconnaître. L'enveloppe ne peut pas être   utilisé comme moyen d'éviter le nom   les collisions entre les éléments de la bibliothèque.

     

Ne supposez pas que toute la programmation   les langues sont sensibles à la casse. Elles sont   ne pas. Les noms ne peuvent pas différer selon les cas   seul.

Answer 12

Je pense que la raison pour laquelle il est sensible à la casse est qu’Unix est sensible à la casse. Dennis Ritchie, le père de C, a également co-écrit Unix. Il est donc logique que le langage qu’il a écrit coïncide avec l’environnement disponible à ce moment-là. C # vient d'hériter cela de son ancêtre. Je pense que c'était une bonne décision de la part de Microsoft, étant donné que les chemins Windows ne sont pas sensibles à la casse.

Answer 13

Je suppose que vous aimeriez voir du code tel que:

SomeField=28;
someField++;
somefield++;
SOMEFIELD++;

compilé comme si SomeField, quelle que soit la variante de boîtier, était la même variable.

Personnellement, je pense que c'est une mauvaise idée. Il encourage la paresse et / ou l'insouciance. Pourquoi s'embêter à bien emballer la chose quand ça n'a pas d'importance quand même? Pendant que nous y sommes, le compilateur devrait peut-être autoriser les fautes d'orthographe, comme SoemField++?

Answer 14

Nom. Les noms sont difficiles à trouver et vous ne voulez pas avoir à créer un nouveau nom lorsque vous parlez de quelque chose de similaire ou à utiliser une notation pour les distinguer.

De tels scénarios sont des propriétés de champs ou des arguments du constructeur que vous êtes sur le point d’affecter aux champs.