Pourquoi les gens aiment-ils la sensibilité à la casse? [fermé]

Question

Je me demandais 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, c'est tout.
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 #. Je l'habitude de.

Alors pourquoi l'aimez-vous?

A bientôt

Answer 1

Cohérence. Le code est plus difficile à lire si "foo", "Foo", "fOO", et "foo". sont considérés comme identiques.

CERTAINES PERSONNES NOUS É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

Answer 2

Un avantage de VB.NET est que, bien qu’il ne soit pas sensible à la casse, l’EDI reformate automatiquement tout le contenu en format "officiel". cas pour un identifiant que vous utilisez - il est donc facile d'être cohérent, 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 constate que je tape toujours sur Ctrl-Espace pour ne pas avoir à 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, car cela peut donner lieu à des malentendus si une grande partie de celle-ci se répandait, je vous recommande donc de ne pas en parler à la demande. ou au niveau du sous-système, mais ne le permettant qu'en interne à une fonction, une méthode ou une classe.

Answer 3

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 agaçant d’essayer de 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 rester droit dans un très grand 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 de dénomination. C’est la convention de dénomination qui a ajouté la valeur, pas la sensibilité à la casse.

Answer 4

Je maintiens 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 un autre même nom et cas différent provoqueront une erreur.

Dim abc = 1
Dim y = Abc - 1 ' error, case doesn't match "abc"
Dim ABC = False ' error, can't redeclare variable "abc"

Il ne tient pas compte de la casse pour le moment, donc je pourrais probablement corriger les quelques erreurs existantes et personne ne se plaindre trop ...

Answer 5

Beaucoup de gens qui aiment la sensibilité à la casse ne comprennent pas ce que signifie la sensibilité à la casse dans .

VB .NET respecte 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 des autres, l’EDI le changera automatiquement au bon formulaire.

L’insensibilité à la casse signifie que vous pouvez taper

dim a as string

et VS le changeront automatiquement pour le cas correctement

Dim a As String

En pratique, cela signifie que vous n’avez presque jamais à appuyer sur la touche Maj, car vous pouvez saisir toutes les minuscules et laisser l’EDI corriger pour vous.

Mais C # n’est pas si mauvais à propos de cela. Intellisense en C # est beaucoup plus agressif qu’il ne l’était dans VS 2002 et 2003, de sorte que le nombre de frappes au clavier diminue un peu.

Answer 6

Je pense que cela renforce la cohérence, ce qui améliore la lisibilité du code et permet à votre œil de mieux analyser les éléments.

class Doohickey {

  public void doSomethingWith(string things) {
     print(things);
  }
}

L'utilisation de conventions de casse rend ce code très normalisé par rapport à 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(string 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 casse ou les normes de casse facilitant la lecture du code.

Answer 7

Je pense qu'il est important que vous compreniez la différence entre la sensibilité à la casse et 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 n’est pas sensible à 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 existe une différence mineure, à savoir que VB vous permettra de taper fOo ultérieurement, mais il s’agit principalement d’une question de lisibilité et, espérons-le, corrigée par une certaine forme de complétion de code.

Ce qui peut être extrêmement utile, c’est quand vous voulez avoir des instances de vos objets. Si vous utilisez une convention de dénomination cohérente, il peut devenir très facile de voir d'où proviennent vos objets.

Par exemple: FooBar fooBar = new FooBar ();

Lorsqu'un seul type d'objet est requis, la lisibilité est considérablement améliorée car il est immédiatement évident de ce que cet objet 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 logique d’utiliser le nom de la classe avec un premier caractère minuscule plutôt qu’un système comme myFooBar, x ou une autre valeur arbitraire que vous oublierez ce qu'elle 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.

Answer 8

Il y a beaucoup de réponses ici, mais je suis surpris que personne ne mentionne 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 pour les cas de chameaux.

Answer 9

Cela vous donne plus d'options.

Bell cloche BEll

sont tous différents.

En outre, cela motive les débutants embauchés à essayer de savoir pourquoi les totaux ne sont pas exacts; o)))

Answer 10

Parce que vous devez maintenant 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 rencontrer de problèmes pour trouver des noms sensibles à la casse.

Answer 11

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 d'être sensible à la casse!

Answer 12

Je pense qu'il y a aussi un problème de psychologie impliqué ici. Nous sommes 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, lorsque je tape

(liste 'a' b 'c)

dans LISP (dans le REPL), et il répond par

(A B C)

mon esprit s’exclame immédiatement: "Ce n’est pas ce que j’ai dit!". Lorsque les choses ne sont pas identiques, elles sont différentes et doivent être prises en compte de manière ...

Answer 13

Je passe généralement du temps avec Delphi en vacances, et la plupart du temps, je n’utilise que C ++ et 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 casse, car des mots similaires (fonctions, variables) se ressemblent et j'aime la non-casse, car cela n'impose pas de restrictions excessives à la syntaxe.

Answer 14

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 15

C'est utile pour distinguer les types dans le code.

Par exemple en Java: Si elle commence par une lettre majuscule, c'est probablement une classe. si sa ALL_CAPS est probablement une constante.

Cela donne plus de polyvalence.

Answer 16

On se sent comme une manière plus professionnelle de coder. Le compilateur ne devrait pas avoir besoin de comprendre ce que vous vouliez dire.

Answer 17

J'ai ressenti 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 souvent maintenant.

Answer 18

C'est également une bonne habitude si vous travaillez sous Linux où le référencement des noms de fichiers est sensible à la casse. Je devais porter une application Windows ColdFusion pour fonctionner sous Linux et ce fut un cauchemar total. Certaines bases de données ont également la sensibilité à la casse activée, imaginez la joie qui y règne.

C’est une bonne habitude quelle que soit la plate-forme et conduit certainement à un style de développement plus cohérent.

Answer 19

IMHO, c’est une question d’habitude. Celui que vous avez l'habitude de sembler naturel et juste.

Vous pouvez trouver de nombreuses explications quant à savoir si c'est bon ou mauvais, mais aucune d’entre elles ne contient beaucoup d’eau. Par exemple:

• Vous obtenez plus d'identificateurs possibles, par exemple. foo vs Foo vs FOO .
• Mais avoir des identifiants qui ne diffèrent que par des cas n'est pas une bonne idée
• Vous pouvez coder les informations de type dans un nom (par exemple, FooBar = nomtype, fooBar = fonction, foo_bar = variable, FOO_BAR = macro)
• Mais vous pouvez le faire quand même avec la notation hongroise

Answer 20

Parce que c'est ainsi que fonctionne le langage naturel.

Answer 21

En matière de programmation, il convient de tenir compte de la casse, par exemple, 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.

Cependant, dans un système d’exploitation, la sensibilité à la casse est tout simplement folle. Je ne souhaite vraiment pas que les fichiers Foo et foo et fOO se trouvent dans le même répertoire. Cela me motive à chaque fois que je fais des trucs * nix.

Answer 22

Pour moi, la sensibilité à la casse est juste 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 portées et la sensibilité à la casse vous aide à le faire sans recourir à des préfixes.

Ouf, au moins nous n'utilisons plus la notation hongroise.

Answer 23

Après avoir travaillé pendant 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 y ont contribué).

En C #, nous pouvons définir des conventions de dénomination que tout le monde doit 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 qu’il 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 point de révision et de maintenance du code n’est pas la meilleure solution, car il est plus facile de parcourir le code à la recherche de 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" ...

Answer 24

Les langages insensibles à la casse ne se généralisent pas facilement aux jeux de caractères non-ASCII. La conversion de casse correcte pour une langue autre que l'anglais n'est pas une tâche simple et dépend notamment des paramètres régionaux du système.

Answer 25

L’insensibilité à la casse est très difficile, sauf si vous limitez la syntaxe à l’ascii (ou appliquez uniquement l’insensibilité à la casse aux caractères ascii), et si vous devez également restreindre les paramètres régionaux.

Les règles permettant de déterminer les minuscules et les majuscules de 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 le type de majuscule approprié.

(Certains langages et environnements permettent d'utiliser presque des caractères dans les noms)

Envisagez de en C # quelle est la différence entre ToUpper () et ToUpperInvariant ()?