Dans une déclaration de condition (IF), tout le monde l'utilise (position < size)
, mais pourquoi?
Seule convention ou il y a une bonne raison à cela?
Trouvé à l'état sauvage:
if (pos < array.length) {
// do some with array[pos];
}
Rarement trouvé:
if (array.length > pos) {
// do some with array[pos];
}
if (MIN <= x && x <= MAX)
. (Dans certaines langues, cela peut être écrit ainsiMIN <= x <= MAX
; en C, c'est parfaitement légal mais ne signifie pas ce que vous pourriez penser que cela signifie).[min, max]
et non[max, min]
. Par conséquent, il est naturel de vérifier qu'un élémentx
appartient à l'intervalle en écrivantmin <= x <= max
.Réponses:
Le modèle le plus profond est que nous utilisons naturellement «[chose qui varie] [comparaison] [chose qui ne varie pas]» comme ordre standard. Ce principe est vrai pour votre exemple car la position peut varier, mais pas la taille.
La seule exception courante est lors du test d'égalité, certains programmeurs s'entraînent à utiliser l'ordre inverse (connu sous le nom de conditions Yoda ) afin d'éviter le commun
variable = constant
plutôt que levariable == constant
bogue - je ne m'en tiens pas à cette idée car je trouve l'ordre naturel décrit ci-dessus beaucoup plus lisible, principalement parce que c'est la façon dont nous exprimons l'idée en anglais, et parce que la plupart des compilateurs modernes le détectent et émettent un avertissement.la source
variable = constant
construction.constant == variable
phénomène.if(DBNull == row["fieldName"]) methodCall()
et je me suis demandé si je devenais fou parce que la plupart du temps je l'ai vu faire l'inverse.(position < size)
exprime souvent une limite supérieure, donc en fait, il reformule une partie delowerbound <= position < upperbound
, avec la taille comme limite supérieure. Avec les deux contraintes explicites, leposition
ne peut aller qu'au milieu.La seule justification que j'aie jamais vue est que c'est comme des lignes de nombres ou d'autres choses d'ordre que nous avons apprises à l'école. Par exemple, nous écrivons des lignes numériques comme ceci:
Les petites choses apparaissent à gauche des grandes choses. La même chose s'applique à d'autres choses telles que les dates (pensez à la façon dont un calendrier est présenté).
Cela se résume essentiellement à la façon dont nous pensons naturellement à l'ordre des choses. Il est plus facile de lire le premier formulaire car vous n'avez pas besoin de faire beaucoup de traitement mental dessus.
la source
Bien que ce soit principalement une question de convention, je pense que cela correspond le mieux à notre façon de penser - cela montre l'élément sur lequel nous mettons l'accent.
Si nous les traduisons en anglais, ce serait l'expression "si la position est inférieure à la longueur du tableau", où le sujet de la phrase est l'élément transitoire.
Pour l'exprimer dans l'autre sens, "si la longueur du tableau est supérieure à la position" met la longueur du tableau (supposée être une valeur fixe) dans le sujet et la position (transitoire) devient l'objet direct.
la source
Mon avis, et ce n'est que mon avis, est que c'est une convention de lisibilité. Bien que les deux soient identiques, ils se sentent différents dans mon cerveau. Je ne veux pas savoir si la taille du tableau est supérieure à la pos. Je veux savoir si pos est plus petit que la taille du tableau.
C'est comme une discussion à moitié vide vs à moitié pleine. Mathématiquement identiques, mais mon cerveau les verra différemment selon le contexte.
Personnellement, si je vois
Je vais commencer à penser si c'est un bug et ce que le programmeur voulait dire. Essaie-t-il de faire autre chose que la vérification des limites?
Peut-être que je ne suis tout simplement pas brillant, mais si je dois faire ce genre d'analyse sur chaque ligne de code, mon cerveau me fait mal.
la source
Pour exprimer ce que certains ont essayé de faire, d'une manière différente ...
Lorsque l'ordre ne fait aucune différence dans le comportement du programme, la différence est clairement une question de ce qui est le plus lisible pour les humains. Voici une raison linguistique pour laquelle mettre le «sujet» à gauche est logique:
En linguistique, le sujet d'une phrase est ce dont on parle, et le commentaire est ce qui est dit sur le sujet. Dans cet exemple, nous pouvons supposer que
position
c'est le sujet et "moins que la longueur du tableau" est le commentaire . En anglais et dans de nombreuses autres langues, le sujet est généralement exprimé avant le commentaire." La tendance à placer les constituants topiques au début de la phrase (sujet) est très répandue. "
Donc , une bonne règle de base est de penser à votre ligne de code comme une phrase (ou clause, dans ce cas), décider de ce que la phrase est au sujet , et de mettre ce premier si vous le pouvez. Souvent, l'objet de la phrase sera une variable plutôt qu'une constante. Mais parfois, le commentaire impliquera également une variable, vous ne pouvez donc pas vous contenter de cela.
la source
C'est une combinaison de deux choses, provenant toutes deux de l'assembleur sous-jacent dans lequel les premiers langages ont été compilés (et de nombreux langages actuels aussi).
Les tableaux sont des décalages de base zéro en mémoire (c'est-à-dire que le premier bloc de données est au début du bloc de mémoire alloué ... l'index 0). D'où l'utilisation de 0..n-1 pour la pièce variable.
La ramification si une valeur est inférieure à une autre valeur (ou registre, etc.) est généralement une instruction unique. D'où l'utilisation de l'opérateur simple inférieur à (<).
Ainsi, le modèle est passé de l'ancien assembleur à ANSI-C (qui ressemble plus à un assembleur de macros à certains égards) et de là à Java et aux autres langages de type C.
la source
Comme beaucoup d'autres réponses l'ont dit, il est très souvent plus facile à lire:
Presque tout le monde que je connais utilise exclusivement ce style.
Il existe une exception, pour les langages de style C qui utilisent
=
pour l'affectation et==
pour la comparaison. Si vous tapez accidentellement:au lieu de:
alors vous n'obtiendrez pas d'erreur car il s'agit d'une ligne de code valide. (Certains compilateurs et IDE vous avertiront de le faire, mais il est toujours très facile d'avoir une faute de frappe aussi simple.)
Cependant, si vous écrivez:
le compilateur / interprète générera une erreur car ce n'est pas une construction valide (dans la plupart des langues, de toute façon).
Cette commutation est souvent appelée condition Yoda .
MISE À JOUR : Voici une liste des endroits où les conditions Yoda sont utiles .
la source
Personnellement, je préfère ceci:
... c'est plus de code, mais c'est aussi très facile à lire.
la source
pos
d'être> array.length
. En d'autres termes, même si cela rend le sens du conditionnel très clair, cela rend en fait un peu plus difficile à lire l'OMI.C'est une question de préférence ou de convention. Si vous voulez être cohérent, il existe deux façons tout aussi raisonnables de procéder:
Mettez toujours le «sujet» en premier (pensez-y comme une phrase) - la valeur sur laquelle porte le test. Ainsi, par exemple, vous écririez
if (age>5)
Ou placez toujours le plus petit élément en premier (pensez-y car les valeurs sont ordonnées sur votre écran dans l'ordre naturel). Ainsi, par exemple, vous écririez
if (a<b)
que ce code concerne principalement a ou principalement b.Les deux conventions recommandent le premier extrait que vous avez montré au lieu du second, donc je suppose que dans ce cas particulier, vous avez votre réponse. Je dirais qu'il est sage d'éviter d'écrire du code qui viole à la fois (1) et (2) ici, car cela rendra la lecture plus difficile pour la plupart des gens.
la source