Dupliqué possible:
Quelqu'un d'autre Trouvez des cours de nommage et des méthodes l'une des parties les plus difficiles de la programmation?Parfois, il semble que je ne peux pas vraiment trouver un nom pour une fonction que j'écris, peut-il être parce que la fonction n'est pas assez cohérente?
Que faites-vous quand aucun bon nom pour une fonction ne vous vient à l'esprit?
8 Réponses :
Donnez-lui votre meilleur tir et votre facteur de nouveau plus tard si cela ne correspond toujours pas.
aller à www.thesaurus.com et essayer de trouver un nom mieux adapté, bien que Synonymes.
Cela vient également avec l'expérience. Il y a de nombreux mots magiques dans la programmation comme: gestionnaire, répéteur, constructeur, utils, convertisseur, manager, etc. Lorsque vous lisez beaucoup de code et de livres sur la programmation, vous trouverez des mots et des situations quand ils peuvent être utilisés.
Habituellement, quand quelque chose est le mieux nommé "Manager", vous avez un problème.
Je ne suis pas d'accord. En .net, vous avez beaucoup de gestionnaires. Je ne dirais pas qu'ils sont mal nommés ou que .Net avez des problèmes dans ces parties particulières. Le gestionnaire n'est qu'un nom comme tout autre. Départ: CommandManager, ApplicationManager, ResourceManager, PropertyManager, SecurityManager ... Je pourrais nommer au moins 100 gérants dans le cadre .NET.
Faites pas utiliser un thésaurus pour proposer 213 façons de former le même concept de noms. Ici (à Stark Difference à la prose), répéter les mêmes mots est bon en ce qui aidait le lecteur à comprendre ce qui se passe ou voir des similitudes.
Parfois, cela pourrait être que votre fonction est trop grande et donc faire trop de choses. Essayez de fractionnez votre fonction dans d'autres fonctions et il peut être plus clair que vous devez appeler chaque fonction individuelle.
Ne vous inquiétez pas de nommer des choses avec un ou deux mots. Parfois, si des fonctions font quelque chose qui peut être expliqué dans une mini-phrase de tri, allez-y et nommer la fonction un peu plus longtemps si cela aidera les autres développeurs à comprendre ce qui se passe.
Une autre suggestion est d'obtenir des commentaires des autres. Souvent, d'autres personnes qui viennent d'une autre perspective et qui voyaient la fonction pour la première fois auront une meilleure idée de quoi appeler la fonction.
presque aussi important que le nom de la fonction est que vous êtes cohérent avec des commentaires. Beaucoup d'idées utilisent vos commentaires correctement formatés pour fournir une aide sensible au contexte pour une fonction que vous pourriez utiliser, mais elles peuvent être utilisées pour générer de la documentation. C'est Dans les paramètres académiques, ils fournissent une démonstration appréciée de vos intentions.
Une bonne règle de base est [verbe] retournée. Ceci est facile avec les fonctions de type GetName () et ne peut pas être appliquée universellement. Il est difficile de trouver un équilibre entre le code non obstrué et descriptif.
voici un Guide de la Convention .NET , mais il est applicable à la plupart des langues.
Je suis tout à fait en désaccord. Je trouve fréquemment que le meilleur code commenté est le plus difficile à lire, et généralement également le plus sujet d'erreur. Lors des enseignants UNI nous diraient que le code commentaire était le PJ de la chat, mais des années d'expérience m'ont appris autrement. Un bon code est vraiment du code qui ne nécessite aucun commentaire intégré, car les fonctions sont à l'autre de l'architecture Systemes. "Savoyer un sens - pas des commentaires" est ce que je dis toujours.
@Banang j'apprécie la perspective. Le mastic du commentaire est un problème et ne devrait pas être utilisé à la place de la conception. Comme si vous avez dit
@Miagclarke, comme dit le proverbe "," si le code et les commentaires sont en désaccord, ils sont faux. " Il suffit de répéter l'algorithme dans les commentaires est confus / redondant. Juste un aperçu de la fonction, des décisions de conception, des commentaires où quelque chose de délicat est en cours, notez des points problématiques possibles. Ajoutez peut-être une sorte de changelog pour les bugs (ou peut-être confier à celui-ci à votre version de votre version de la version, avec suffisamment de détails ).
Je trouve plus facile de nommer des fonctions lorsque je n'ai pas à réduire les mots. Tant que vous ne faites pas de JavaScript pour la page de démarrage de Google, vous pouvez faire des noms plus longs.
Par exemple, vous avez la méthode Tant qu'il est clair, quelle que soit la fonction, vous pouvez nommer ce que vous voulez et le refacteur plus tard. DEQUUEREREUSABLECELLWIDIdentifier et MergechangesfromContextTextExtextextextextextextextextextextextextext dans le cadre de cacao de pommes.
ifthenameissolongitiseasytoconfuseitwithhanthersImarès, c'est juste un nom Bad Nom. "Refactor plus tard" ne se produira jamais, car vous vous familiarisez avec le nom (mauvais), ou il est utilisé partout et c'est trop de travail pour changer.
Pour les fonctions de dénomination, évitez simplement d'avoir simplement des noms simplement et nommez-les après les verbes. Certains pointeurs:
validateInput () et validateuserinput () car il est difficile de dire ce que l'on fait sur une autre. Évitez également d'avoir des caractères très similaires, par exemple. le nombre 1 et minuscule 'l'. Parfois, cela fait une différence.
- travaillez-vous sur un projet avec plusieurs personnes? Vous devriez également passer du temps à relever des conventions de nommage également, par exemple si le nom de la fonction devrait avoir des traits de soulignement, devrait être camelcase, etc.
- La notation hongroise est une mauvaise idée; Évitez de le faire.
- pense à ce que la fonction fait. La cohésion que vous avez mentionnée dans votre question me vient à l'esprit. Généralement, les fonctions doivent faire une seule chose, alors ne le nommez pas
construccarandruncar () mais plutôt une fonction qui construit et une autre qui le gère. Si vos fonctions sont comprises entre 20 et 40 lignes, vous êtes bon.
- Parfois, cela dépend du projet, vous pouvez également souhaiter préfixer vos noms de fonction avec la classe si la classe est purement procédurale (uniquement composée de fonctions). Donc, si vous avez une classe qui prend soin d'exécuter une simulation, nommez vos fonctions
SIM_PAUSUIMULATION () et SIM_RESTARTSIMULATION () . Si votre classe est basée sur OOP, ce n'est pas un problème autant.
- n'utilisez pas les structures de données sous-jacentes dans les fonctions elles-mêmes; Ceux-ci devraient être abstraits. Plutôt que d'avoir des fonctions telles que
addtoVector () ou addtoarray () , demandez-leur d'être addtolist () . Ceci est particulièrement vrai si ce sont des prototypes ou que les structures de données peuvent changer plus tard.
- Enfin, soyez cohérent dans vos conventions de dénomination. Une fois que vous avez trouvé une convention après une pensée, tenez-y. PHP vient à l'esprit en pensant à des noms de fonction incohérents.
codage heureux! :)
WOW, belle liste, la notation hongroise est une partie des pires choses que MS multipagées, même des problèmes ont des problèmes de se débarrasser du démon libéré ...
Parlez-moi de cela :) J'ai travaillé chez Mme dernier été et la notation hongroise était terrible. Imaginez avoir un long pointeur sur une chaîne WCHAR: lpwstr * .
Je n'utilise pas personnellement la notation hongroise et je n'ai jamais eu - mais qu'en est-il de cela le rend si terrible?
L'ajout du type était inutile pour moi car en tant que programmeur et développeur, j'ai senti que je devrais connaître la fonction et les types de données que je traite. Comme je l'ai déjà dit, cela est particulièrement mauvais si vous refactez le code. Au lieu d'avoir une liste liée appelée clientlist, vous auriez LLClientList avec HN. Si vous décidez qu'un tableau est meilleur, vous devez également modifier toutes les autres instances de la variable et vous êtes obligé de penser à ce type lors de l'utilisation de variables avec HN, ne pas utiliser comme cela devrait être.
@Jamie Il montre une mise au point prédominante sur les types. La programmation a évolué de nos jours à l'endroit où l'utilisation et les interfaces sont plus importantes que les types réels que nous utilisons. De plus, lorsque SHC a signalé, si un type change jamais, il nécessite de modifier le nom de chaque instance où le type est utilisé dans le code client même si l'interface et l'utilisation reste exactement la même. Enfin, il charge les utilisateurs des détails de la mise en œuvre qu'ils n'ont peut-être même pas à connaître. Beaucoup de classes et de structures de Windows API, par exemple, peuvent aussi bien être opaques à l'utilisateur: ils les transmettent simplement dans des fonctions API.
[...] L'information n'est pas pertinente, pour ainsi dire. Enfin, si on écrit le code d'une manière où l'on doit connaître le type exact d'un objet et ce n'est pas évident, le code doit probablement être mieux organisé. La notation hongroise n'est pas une excuse pour écraser 2000 fonctions de ligne ou une classe / structure avec 500 membres.
@ stky472 bonne explication - merci
@JDEHAAN: Notation hongroise: Certaines personnes l'aiment, certains détestaient-le. Personnellement, j'adore ça et cela m'aide à repérer des erreurs (par exemple, nommer le conteneur VEC, carte, LST ou DEQ vous aide à voir si ses variantes d'itérator ne sont pas cassées). Je ne suis pas un grand fan de cette convention "auto" Certains gourous de C ++ sont dictés. Cependant, la notation hongroise est plus pour les variables que pour la nommage de la fonction.
@ stky472 bonne explication.
I Suivre la règle suivante: Nom selon le but Pour les fonctions, il s'agit presque toujours d'une action (verbe) suivie du nom de paramètres et (ou des résultats. (hors sujet mais pour les variables n'utilise pas "Arrayofnames" ou "ListofNames", ce sont des informations de type mais simplement "noms") . Cela évitera également des incohérences si vous refactez le code en partie.
Pour des motifs donnés comme la création d'objets, soyez cohérent et utilisez toujours le même nommé comme "Créer ..." (et pas parfois "allouer ..." ou "construire ..." ou "construire ..." sinon " vous ou vos collegues finira par gratter la blessure de leur tête)
en règle pratique de la mienne, si un nom de fonction est trop long, il devrait être atomisé dans un nouvel objet. Pourtant, je suis d'accord avec tous les messages ci-dessus. BTW, belle question noob
Il y a deux problèmes difficiles en informatique: (1) Invalidation de cache; (2) nommer des choses; (3) Erreurs hors-tête.
Dupliquer: Stackoverflow.com/Questtions/421965/...
@Greg Hewgill: Je parie si Phil Karlton était toujours en vie, il aimerait ça.