En ce qui concerne la dénomination des Rails, il existe de nombreuses descriptions pour le modèle, le contrôleur et les tables, mais il semble qu'il n'y ait pas beaucoup d'écrit sur les noms de méthode, les noms de variables et les noms de portée.
Un bon ou un mauvais nommage a un gros impact sur la lisibilité du code, mais d'un autre côté, nous qui ne sommes pas bons en anglais donnons souvent des dénominations sanglantes et accumulons souvent des dettes techniques.
En premier lieu, ruby a une spécification de langage qui est consciente du goût d'écriture anglais ("poi" jusqu'au dernier), donc je pense que les noms de méthodes, les noms de variables et les noms de portées devraient suivre dans une certaine mesure cette manière. Par conséquent, j'ai reconsidéré les lignes directrices que ces noms devraient suivre.
Je vais l'écrire de différentes manières, donc j'aimerais le subdiviser. Cette fois, j'ai pensé à nommer la méthode, la portée et (un peu) variable du modèle, mais je penserai au contrôleur plus tard.
| Nommer la cible | format |
|---|---|
| portée | "Adjectif (phrase)","préposition_nom",«Vibration»,"Ancienne forme participative du verbe" |
| Méthode avec action | "Autre verbe" → L'objet de l'autre verbe doit être l'objet récepteur! |
| Méthode de jugement | "Adjectif (phrase)?」,"préposition_nom?」,"Vibration ing?」,"Ancienne forme participative du verbe?」 |
| Méthode sans effet | "Nomenclature (phrase)" → Peut être utilisé comme propriété |
| Méthode pour transformer l'objet lui-même | 「to_nom" |
| variable | "Nomenclature (phrase)" |
| Variables (exceptions) | "Ancienne forme participative du verbe_préposition(_Nomenclature) »→ Évitez si vous pouvez l'éviter |
Faites attention à la partie du mot que vous utilisez. Et le plus important est de lire et de comprendre le sens.
Doit être un adjectif ou une phrase adjectif. Le nom de la portée post-qualifie le nom du modèle. Utilisez la partie «quoi» de «quel OO» comme nom de portée. Le nom du modèle est entré dans 〇〇.
Si la portée est nommée de manière à être post-modifiée avec une phrase adjectif, elle ne cassera pas dans la grammaire anglaise même lorsque la portée est enchaînée.
Book.in_sale.published_by("O'Reilly") ← Book (which is) in sale published by O'Reilly
Shop.selling_books #Magasins vendant des livres
Task.not_running #Forme négative
Book.published #Ancienne forme participative
Book.published_by("O'Reilly") #Portée qui prend également des arguments
Book (which is) published by O'Reilly
C'est un bon nom pour ressembler à une nomenclature avec le (qui est) omis.
Shop.without_blue_roof
Devil.in_the_prada
Man.with_the_machine_gun
Mission.impossible
Daemon.alive
Picture.not_displayable
Tower.taller_than(100)
Session.expired #Supplément)expired peut être considéré comme un adjectif ou une forme participative passée d'un mot automatique (il n'y a pas de grande différence)
Parfois, je vois les noms de portée dans le style : filtered_xxxx, mais ces noms sont redondants car les fonctions de portée sont réduites en premier lieu.
Nous déconseillons également : can_xxxx. Le jugement d'une bonne dénomination est de savoir si ce qui est, qui a été omis en tant que «nom du modèle (qui est) la portée», est réactivé et grammaticalement réduit.
La manière de penser est très différente selon que la méthode implique une action (changement de variables, etc.) ou une méthode qui n'a pas d'action.
"Que faire" avec "sujet (objet appelant)" comme "objet (récepteur)". La partie «que faire» est le nom de la méthode. En conséquence, il modifie l'état des variables internes, agit sur les objets externes et accède aux services externes.
cow.grow # <= I grow up the cow.En conséquence, la vache.L'âge est incrémenté, et ainsi de suite.
file.delete # <= I delete the file.En conséquence, le fichier disparaît sur le système de fichiers externe (pour le programme).
job.perform # <= I perform the job.
Parfois, je vois des méthodes où le récepteur (objet) est le sujet, mais ce n'est pas bon. Cela peut sembler bon pendant un moment, mais à long terme, il n'est plus orienté objet et commence à s'effondrer.
#mauvais exemple
manager.evaluate(member) # <=Un manager évalue son membre tel qu'il est.
Les méthodes basées sur le jugement (non agissant) qui renvoient «vrai» ou «faux» ont une approche de dénomination distinctement différente de celle des méthodes normales (agissant). Seulement dans ce cas, le récepteur est traité comme le sujet.
Par exemple, l'instruction qui détermine si Shop est à l'état ouvert
shop.open? # <= Is the shop open?
Dans d'autres langues, nous faisons souvent des méthodes de jugement avec la colle avec le verbe be shop.is_open.
Dans Ruby / Rails, le verbe be est généralement omis et un «?» Est ajouté à la fin. Je pense que c'est une culture propre à la spécification du langage qui «?» Peut être utilisé, et en premier lieu, «S + V + C» devient «V + S + C?», Donc «est entre le sujet et le complément «N'entre pas.
Seulement dans le cas d'une méthode de jugement, le nom de la méthode doit être "complémentaire". (S = objet, V = omis, C = nom de la méthode) → Semblable à la dénomination des portées, elle est basée sur "adjection?", "Préfixe + nez?", "Vibration + ing?", Ou "forme participative passée du verbe?".
Y a-t-il ou non can_xxx, can_be_yyy? Je pense qu'il vaut mieux l'éviter autant que possible. J'y penserai plus tard.
Ne créez pas autant que possible une méthode appelée shop.not_open?. Tout ce que vous avez à faire est d'écrire «! Shop.open?».
Si les conditions de jugement se compliquent, la lisibilité de la méthode diminuera également, donc je pense qu'il est bon de la concevoir de manière à ne pas inclure la signification du déni en premier lieu.
Pour les méthodes qui ne retournent pas «true» / «false», il semble préférable de définir celles qui peuvent être utilisées comme propriétés de l'extérieur en tant que propriétés. La dénomination à ce moment est du même style que le "nom de variable" décrit plus loin.
Ou, si vous voulez convertir l'objet lui-même dans un autre format, vous devez le nommer to_xxx. N'utilisez pas convert_to_xxx.
Par exemple
class Sylinder
attr_accessor :bore, :stroke
def initializer(bore, stroke)
@bore = bore
@stroke = stroke
end
def displacement # <=Parce qu'il n'affecte pas l'état interne de l'objet:calculate_N'utilisez pas de noms de méthodes comme le déplacement
(@bore/2) * (@bore/2) * Math::PI * @stroke
end
end
Fondamentalement, je souhaite utiliser une nomenclature comme nom de variable. Les variables sont des attributs appartenant à l'objet (ou à la classe). Le nom de l'attribut est un nom. Vous pouvez affiner la signification en ajoutant un acronyme ou une cote de possession avant la nomenclature.
user.email
user.first_name
Exceptionnellement, une variable qui contient des informations auxiliaires sur une action sur l'objet peut avoir un nom de variable sous la forme de la forme partielle passée du verbe + le préfixe (+ nomenclature). Si vous pouvez l'exprimer sans utiliser de tels noms de variables, je pense que c'est plus facile à lire plus tard si vous l'évitez.
article.created_at
article.published_by
article.referenced_in_indices
automator.call bob if not bob.awake?
De l'endroit où vous pouvez appeler l'argument de la méthode sans parenthèses comme, et de l'endroit où les mots-clés «not», «et» sont définis A l'origine, il est possible d'écrire dans un langage naturel ** comme ** avec une description moins symbolique. Le stress de la lecture de code peut être réduit en concevant la dénomination des portées, des méthodes et des variables de sorte que l'expression ressemble à un langage naturel lors de l'appel.
On sait que la grammaire anglaise est essentiellement classée dans les cinq modèles de phrases suivants.
Je pense que les composants du modèle de phrase et les concepts correspondants dans la programmation Rails sont les suivants.
S: Sujet (partie principale) → Appelant (sujet) V: verbe → méthode O: Objet (nom) → Récepteur (objet qui a la méthode) et argument de méthode (dans le cas du modèle de 4ème phrase) C: Complément (avocat / complément / phrase adjectif / phrase complémentaire) → Valeur de substitution
Le "O" en S + V + O est le "O" en Orienté objet.
Fondamentalement, il semble bon de penser que l'appel de méthode exprime la phrase du modèle de troisième phrase. En dehors de cela, sera-t-il implémenté comme une affectation ou un changement de propriété, ou sera-t-il implémenté en le convertissant en modèle de troisième phrase?
Pas tellement. En effet, l'orientation objet est un paradigme dans lequel l'appelant agit sur le récepteur pour implémenter le processus.
Je pense que le simple file.delete () est en fait le modèle de troisième phrase.
file.delete # <= I deletes the file.
Puisque O (Object) n'apparaît pas, il s'agit également d'un cas rare en tant que formulaire de méthode. Si tel est le cas, je pense que l'objet appelant attribuera quelque chose à sa propriété, ou quelque chose comme ça.
Les variations de V (verbe) qui prennent ce modèle de phrase sont les suivantes.
Type d'état: être, regarder, sembler, apparaître, garder, rester, mentir Variantes: devenir, obtenir, tourner, grandir, fabriquer, venir, partir, tomber Type sensoriel: odeur, goût, sensation, son Source: https://www.eng-builder.jp/learning/sentence-pattern2/
En d'autres termes, bien que ces verbes diffèrent selon qu'ils sont accompagnés de changements ou non, ils expriment tous que S est à l'état de C («S = C») en conséquence. Lors de la description de cette expression par programmation, dans la plupart des cas, il semble que cela puisse être réalisé en attribuant une valeur à la propriété qui représente l'état de l'objet.
alice.health = :fine # <= Alice becomes fine.
C'est facile à comprendre. Cela semble être le plus.
file.delete # <= I delete the file.
window.move_to(100, 300) # <= I move the window to (100, 300).
Je pense que l'argument donné est souvent utilisé comme une phrase complémentaire pour modifier la phrase entière. En bref, l'argument est un paramètre qui ajuste l'action sur l'objet. Je pense que le paramètre devrait être const dans la méthode appelée, mais je n'y ai pas encore pensé.
Les variations de V (verbe) qui prennent ce modèle de phrase sont les suivantes.
give, show, offer, hand, pass, send, teach, tell, pay, lend, do
En tant que tendance, on peut voir que S signifie donner O2 à O1. Lors de l'écriture en programmation orientée objet, je pense que cela peut souvent être exprimé en attribuant / ajoutant des propriétés.
alice.belongings.push book # <= I give Alice a book
alice.give book # <= I give Alice a book
Les variations de V (verbe) qui prennent ce modèle de phrase sont les suivantes.
make, get, keep, leave, think, believe, find, call, name
On peut voir que tous sont des verbes qui expriment l'état O = C. Un verbe qui signifie reconnaître que "un état de O est C" ou "un état de O est C" en conséquence, bien qu'il y ait une différence que S travaille sur O ou non. Cela pourrait être réécrit en une représentation SVC plus simple en utilisant uniquement C et O lorsque vous essayez de l'implémenter orienté objet.
Room.tidiness = :clean # <= I make the room clean.
cat.name = "Tom" # <= I name the cat "Tom."
Je ne sais pas parce que c'est compliqué. Le texte est devenu non coordonné.
L'objet est l'objet How To Name Variables And Methods In Ruby
Recommended Posts