conventions de codage pour l'écriture des années dans cfc CF9?
-
20-09-2019 - |
Question
Avec les nouvelles façons d'écrire CFC dans CF9, ce sont une partie de la convention de codage à nouveau CF9?
Voici quelques-uns, je peux penser à ...
- utilisez toujours portée locale
- toujours inclure méthode
init()
qui se retourne, puisqueNew
va appeler init () se trouve. - faire pas faire valoir des arguments nécessaires à
init()
si elle est une entité ORM, sinon des exceptions ... attendez - utilisez toujours
THIS.setXXX
dans XXX est le nom de propriété à l'intérieur init (), de sorte qu'il appellera les setters implicites ou setter personnalisé si elle est disponible. - abandonner la convention cadre INSTANCE pré-CF8, voir: http://henrylearnstorock.blogspot.com/2009/08/should-we-abandon-instance-scope-in-cf9.html
- pas de sortie = false pour le composant et les fonctions de script dans le style CFC, voir: http://www.coldfusionjedi.com/index.cfm/2009/8/26/Ask-a-Jedi-Impact-of- des espaces blancs et base-script CFC
- utilisez l'aspirateur et
isNull(arguments.optionalArg)
plus efficace au lieu deisDefined()
La solution
ne nous avons encore besoin de définir l'attribut output = false pour composants et fonctions dans le style de script CFC?
Je ne le pense pas. <cfscript>
par sa nature supprime les espaces blancs et les besoins writeOutput()
afin d'avoir une sortie du tout.
Autres conseils
Votre méthode init () ne doit pas retourner le champ « ce » si vous appelez à l'aide de la syntaxe « nouvelle my.cfc () ». histoire vraie.
Si vous êtes à l'intérieur d'un cfc et que vous voulez définir une propriété, ne pas utiliser this.setFoo (), allez setFoo (). Même chose pour getFoo (). Le this.xxx () est comme sortir la porte d'entrée pour revenir. De plus, l'accès = getters personnalisés privés et setters ne fonctionnera pas que les fonctions ne sera pas dans le champ d'application de cette.
"var foo" vs "local.foo" - personnellement, je préfère les variables var'd comme il est a) moins à taper le code, et b) moins de code à lire
.// there isnt a huge difference here
var today = now();
var tomorrow = dateAdd( 'd', 1, today );
local.today = now();
local.tomorrow = dateAdd( 'd', 1, local.today );
// but when you start getting more complex examples, it quickly blows out
var out = method( var1, var2, var3, var4, var5 );
local.out = method( local.var1, local.var2, local.var3, local.var4, local.var5 );
Utilisez les commentaires de style. La documentation est votre ami.
/**
* @hint This is a hint for the whole function
* @arg1 This is an argument hint
* @arg2 This is another argument hint
**/
public void function myFunction( string arg1 = 'default', boolean arg2 ) {
return true;
}
toutes les fonctions qui modifient les données doivent retourner une valeur, même si elle est un booléen qui est actuellement toujours vrai. Les fonctions ont une façon d'avoir besoin de revenir éventuellement false