Vous vous demandez simplement pourquoi les gens aiment la sensibilité à la casse dans un langage de programmation? Je ne cherche pas à déclencher une guerre des flammes, simplement curieux.
Personnellement, cela ne m’a jamais vraiment plu car je constate que ma productivité diminue chaque fois que j’essaie d’utiliser un langage sensible à la casse, mais je me réchauffe lentement et m’y habitue maintenant que j’utilise plus souvent C # et F #. J’avais l’habitude de.
Alors pourquoi tu l’aimes?
À votre santé
Cohérence. Le code est plus difficile à lire si “foo”, “Foo”, “fOO” et “fOo” sont considérés comme identiques.
CERTAINES PERSONNES PEUVENT ÉCRIRE TOUT EN MAJUSCULES, RENDANT TOUT MOINS LISIBLE.
La sensibilité à la casse facilite l’utilisation du “même nom” de différentes manières, selon une convention de capitalisation, par exemple:
Foo foo = ... // "Foo" is a type, "foo" is a variable with that type
Un avantage de VB.NET est que bien qu’elle ne soit pas sensible à la casse, l’EDI reformate automatiquement tout le contenu en cas “officiel” pour un identifiant que vous utilisez – il est donc facile d’être cohérent et facile à lire.
L’inconvénient est que je déteste la syntaxe de style VB et préfère de loin les opérateurs de style C, la ponctuation et la syntaxe.
En C #, je trouve que je tape toujours sur Ctrl-Espace pour éviter de devoir utiliser le type approprié.
Ce n’est pas une bonne idée que de nommer des éléments qui diffèrent d’une affaire à l’autre, cela peut donner lieu à des malentendus si une grande partie de celle-ci s’échappe vers des domaines plus vastes. Je recommande donc de ne pas en parler au niveau de l’application ou du sous-système. niveau, mais en ne le permettant qu’en interne à une fonction, une méthode ou une classe.
La sensibilité à la casse n’impose pas les styles de codage ni la cohérence. Si vous cassez une constante, le compilateur ne se plaindra pas. Cela vous obligera simplement à le taper en utilisant pascal case chaque fois que vous l’utiliserez. Personnellement, je trouve irritant de devoir distinguer deux éléments qui ne diffèrent que par les cas. Il est facile à faire dans un court bloc de code, mais il est très difficile de restr droit dans un très gros bloc de code. Notez également que la seule façon dont les gens peuvent réellement utiliser la distinction entre majuscules et minuscules sans s’écrouler est qu’ils respectent rigoureusement les mêmes conventions d’appellation. C’est la convention de dénomination qui a ajouté la valeur, pas la sensibilité à la casse.
Je gère un compilateur interne pour mon entreprise et je suis tenté de le transformer en hybride. Vous pouvez utiliser le cas où vous voulez pour un identifiant. Vous devez y faire référence avec le même boîtier, mais en nommant autre chose du même nom. cas différent provoquera une erreur.
Dim abc = 1 Dim y = Abc - erreur 1 ', la casse ne correspond pas à "abc" Dim ABC = Faux 'erreur, impossible de redéclarer la variable "abc"
Il est actuellement insensible à la casse, donc je pourrais probablement corriger les quelques erreurs existantes et personne ne se plaindrait trop …
Beaucoup de gens qui aiment la sensibilité à la casse comprennent mal ce que signifie la sensibilité à la casse.
VB .NET est insensible à la casse. Cela ne signifie pas que vous pouvez déclarer une variable en tant qu’abc, puis vous y référer ultérieurement en tant qu’ABC, Abc et aBc. Cela signifie que si vous le tapez comme l’un de ces autres, l’EDI le changera automatiquement au formulaire approprié.
L’insensibilité à la casse signifie que vous pouvez taper
dim a as ssortingng
et VS le changera automatiquement à la casse correcte
Dim a As Ssortingng
En pratique, cela signifie que vous n’avez presque jamais à appuyer sur la touche Maj, car vous pouvez taper en minuscule et laisser l’EDI corriger pour vous.
Mais C # n’est pas si mauvais à propos de cela. Intellisense en C # est beaucoup plus agressif que dans VS 2002 et 2003, de sorte que le nombre de frappes au clavier diminue un peu.
Je pense que cela renforce la cohérence, ce qui améliore la lisibilité du code et permet à votre œil de mieux parsingr les éléments.
class Doohickey { public void doSomethingWith(ssortingng things) { print(things); } }
L’utilisation de conventions de casse rend ce code très normalisé pour tout programmeur. Vous pouvez facilement choisir des classes, des types et des méthodes. Ce serait beaucoup plus difficile à faire si quelqu’un pouvait le capitaliser de quelque manière que ce soit:
Class DOOHICKEY { Public Void dosomethingwith(ssortingng Things) { Print(things); } }
Cela ne veut pas dire que les gens écriraient du code laid, mais les règles de capitalisation et de ponctuation facilitent la lecture, les règles de respect de la casse ou les normes de casse facilitant la lecture du code.
Je pense qu’il est important que vous compreniez la différence entre ce qu’est la sensibilité à la casse et ce qu’est la lisibilité pour répondre correctement à cette question. Bien qu’il soit utile d’avoir différentes stratégies de casage, vous pouvez les avoir dans une langue qui ne respecte pas la casse.
Par exemple, foo peut être utilisé pour une variable et FOO en tant que constante à la fois en Java et en VB. Il y a une différence mineure avec le fait que VB vous permettra de taper fOo ultérieurement, mais ceci est principalement une question de lisibilité et, espérons-le, corrigé par une certaine forme de complétion de code.
Ce qui peut être extrêmement utile, c’est lorsque vous souhaitez avoir des instances de vos objects. Si vous utilisez une convention de dénomination cohérente, il peut devenir très facile de voir d’où proviennent vos objects.
Par exemple: FooBar fooBar = new FooBar ();
Lorsqu’un seul object d’un type est nécessaire, la lisibilité est considérablement améliorée car il est immédiatement évident de ce que cet object est. Lorsque plusieurs occurrences sont nécessaires, vous devrez évidemment en choisir un nouveau (noms qui ont du sens), mais dans les petites sections de code, il est très judicieux d’utiliser le nom de la classe avec un premier caractère minuscule au lieu d’un système comme myFooBar, x ou une autre valeur arbitraire que vous oublierez ce que cela fait.
Bien sûr, tout cela est une question de contexte, mais dans ce contexte, je dirais que 9 fois sur 10, cela en vaut la peine.
Il y a beaucoup de réponses ici, mais je suis surpris que personne n’ait signalé l’exemple évident qui se moque également d’un concurrent à la superposition:
expertSexChange != expertsExchange
La casse est très importante lorsque vous utilisez des noms de variables de casse-chameaux.
Cela vous donne plus d’options.
Cloche cloche
sont tous différents.
En outre, cela motive les débutants embauchés à essayer de savoir pourquoi les totaux ne sortent pas comme il faut; o)))
Parce que maintenant, vous devez tout taper de manière cohérente. Et puis les choses commencent soudain à avoir un sens.
Si vous avez un éditeur correct – un qui intègre IntelliSense ou la même chose sous un autre nom – vous ne devriez pas avoir de problème pour trouver des noms sensibles à la casse.
La sensibilité à la casse est une folie! Quel type de codeur insensé utiliserait des variables nommées foo, foO, fOo et fOO, toutes dans le même champ d’application? Vous ne me convaincrez jamais qu’il y a une raison pour la sensibilité à la casse!
Je pense qu’il y a aussi une question de psychologie impliquée ici. Nous sums des programmeurs, nous distinguons minutieusement les choses. ‘a’ n’est pas la même valeur ASCII que ‘A’, et je me sentirais étrange quand mon compilateur les considère comme identiques. C’est pourquoi, quand je tape
(liste ‘a’ b ‘c)
dans LISP (dans le REPL), et il répond avec
(ABC)
mon esprit s’exclame immédiatement: “Ce n’est pas ce que j’ai dit!” Quand les choses ne sont pas identiques, elles sont différentes et doivent être considérées de manière …
Je passe généralement du temps avec Delphi à programmer, et la plupart du temps, je n’utilise que du C ++ et du MASM. Et une chose est étrange: quand je suis sur Delphi, je n’aime pas la sensibilité à la casse, mais quand je suis sur C ++ – je l’aime. J’aime la distinction entre majuscules et minuscules, parce que cela rend les mots similaires (fonctions, variables) similaires, et j’aime la non majuscules, parce que cela n’impose pas de ressortingctions excessives à la syntaxe.
Extrait du Guide du développeur .NET Framework Conventions de capitalisation , respect de la casse:
Les consignes de capitalisation ont pour seul but de faciliter la lecture et la reconnaissance des identifiants. Les majuscules ne peuvent pas être utilisées pour éviter les conflits de noms entre les éléments de la bibliothèque.
Ne supposez pas que tous les langages de programmation sont sensibles à la casse. Ils ne sont pas. Les noms ne peuvent pas différer par cas seulement.
C’est utile pour distinguer les types dans le code.
Par exemple, en Java: si elle commence par une majuscule, c’est probablement une classe. si sa ALL_CAPS est probablement une constante.
Cela donne plus de polyvalence.
On se sent comme une manière plus professionnelle de coder. Vous ne devriez pas avoir besoin du compilateur pour comprendre ce que vous vouliez dire.
Je ressentais la même chose que vous il y a longtemps, lorsque j’utilisais beaucoup plus le VB3 / 4. Maintenant, je travaille principalement en C #. Mais maintenant, je trouve que l’IDE réussit très bien à trouver les symboles et à donner un bon intellisense sur les différents cas. Cela me donne également plus de flexibilité dans mon propre code car je peux avoir un sens différent pour les éléments avec différents cas, ce que je fais beaucoup maintenant.
C’est également une bonne habitude si vous travaillez sous Linux où le référencement de noms de fichiers est sensible à la casse. J’ai dû porter une application Windows ColdFusion pour fonctionner sous Linux et c’était un véritable cauchemar. De plus, certaines bases de données ont la sensibilité à la casse activée, imaginez la joie que cela procure.
C’est une bonne habitude quelle que soit la plate-forme et conduit certainement à un style de développement plus cohérent.
IMHO c’est entièrement une question d’habitude. Celui que vous avez l’habitude de sembler naturel et correct.
Vous pouvez trouver de nombreuses explications quant à savoir si c’est bon ou mauvais, mais aucune d’entre elles ne retient beaucoup d’eau. Par exemple:
foo
vs Foo
vs FOO
. FooBar
= nom_type, fooBar
= fonction, foo_bar
= variable, FOO_BAR
= macro) Parce que c’est comme ça que le langage naturel fonctionne.
En matière de programmation, il y a quelque chose à dire sur la sensibilité à la casse, par exemple avoir une propriété publique Foo et un champ privé / protégé correspondant foo. Avec IntelliSense, il n’est pas très difficile de ne pas commettre d’erreur.
Toutefois, dans un système d’exploitation, la sensibilité à la casse est tout simplement folle. Je ne veux vraiment pas avoir un fichier Foo , Foo et FOO dans le même répertoire. Cela me motive à chaque fois que je fais des trucs * nix.
Pour moi, la sensibilité à la casse n’est qu’un jeu sur des étendues comme thisValue pour un argument et ThisValue pour une propriété ou une fonction publique.
Plus que souvent, vous devez utiliser le même nom de variable (car il représente la même chose) dans différentes étendues et la sensibilité à la casse vous aide à le faire sans recourir à des préfixes.
Ouf, au moins nous n’utilisons plus la notation hongroise.
Après avoir travaillé de nombreuses années avec le code ASP VBScript hérité, lorsque nous avons migré vers .NET, nous avons choisi C #, et l’une des principales raisons était la sensibilité à la casse. L’ancien code était illisible car les gens ne suivaient aucune convention: le code était un gâchis illisible (bon, les pauvres IDE VBScript ont aidé à cela).
En C #, nous pouvons définir des conventions de nommage et tout le monde doit les suivre. Si quelque chose n’est pas correctement mis en cas, vous pouvez le renommer (avec refactoring, mais c’est une fonctionnalité de l’EDI) et il n’y aura aucun problème car la classe ou la variable sera nommée de la même manière dans tout le code.
Enfin, je pense est beaucoup plus lisible si tout est correctement mis en cas. Il est peut-être plus rapide d’écrire sans tenir compte de la casse, mais partir d’un sharepoint révision et de maintenance du code n’est pas la meilleure solution car il est plus facile de parcourir le code en recherchant quelque chose. Par exemple, il est plus facile de trouver toutes les chaînes “foo” en un coup d’œil que de chercher “foo”, “Foo”, “FOO”, “FOo” …
Les langages insensibles à la casse ne se généralisent pas facilement aux jeux de caractères non-ASCII. La conversion correcte de casse pour une langue autre que l’anglais n’est pas une tâche simple et dépend notamment des parameters régionaux du système.
L’insensibilité à la casse est très difficile, sauf si vous limitez la syntaxe à ascii (ou appliquez uniquement l’insensibilité à la casse aux caractères ascii), et vous devez également restreindre les parameters régionaux.
Les règles permettant de déterminer les majuscules et les minuscules des caractères ne sont ni bien définies ni sans perte.
Certains caractères peuvent avoir plus d’une forme ‘minuscule’. Certaines personnes ne seront pas d’accord sur la forme exacte de la majuscule.
(Certaines langues et certains environnements permettent d’utiliser presque des caractères dans les noms)
Considérez en C # quelle est la différence entre ToUpper () et ToUpperInvariant ()?