Codificación de convenciones para la escritura de CFC en CF9?

Question

Con las nuevas formas de escritura de CFC en CF9, ¿cuáles son algunas de las convenciones de codificación nuevo a CF9?

Aquí están algunos que puedo pensar ...

• utilizar siempre alcance LOCAL
• siempre incluyen init() método que devuelve sí mismo, ya New llamará init () si se encuentra.
• no puesto requerido argumentos en init() si se trata de una entidad ORM, de lo contrario esperar excepciones ...
• utilice siempre THIS.setXXX en donde XXX es el nombre de propiedad dentro de init (), por lo que va a llamar a los emisores implícitas o colocador de encargo si está disponible.
• abandonar la CF8 pre-INSTANCIA convención alcance, ver: http://henrylearnstorock.blogspot.com/2009/08/should-we-abandon-instance-scope-in-cf9.html
• ninguna salida = false para los componentes y funciones en escritura CFC estilo, ver: http://www.coldfusionjedi.com/index.cfm/2009/8/26/Ask-a-Jedi-Impact-of- basada en los espacios en blanco-y-script-CFC
• utilizar el isNull(arguments.optionalArg) más limpia y más eficiente en lugar de isDefined()

Answer 1

  

Qué necesidad tenemos ya de establecer atributo de salida = false para los componentes y funciones en CFC estilo de la escritura?

No me lo creo. <cfscript> por su naturaleza suprime cualquier espacio en blanco y necesita writeOutput() el fin de tener ninguna salida en absoluto.

Answer 2

Su método init () no tiene que devolver el "este" ámbito si está llamando a que el uso de la "nueva my.cfc) (" sintaxis. Es una historia verdadera.

Si está dentro de un CFC y desea establecer una propiedad, no uso this.setFoo (), sólo tiene que ir setFoo (). Lo mismo va para getFoo (). El this.xxx () es como ir a la puerta principal sólo para volver. Además, el acceso al usuario = captadores y definidores personalizados privados no trabajará como las funciones no será en el este alcance.

"foo var" vs "local.foo" - personalmente, prefiero las variables var'd ya que es a) menos código para escribir, y b) menos código para leer

.

// 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 );

Use javadocs comentarios de estilo. La documentación es su amigo.

/**
* @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;
}

Answer 3

todas las funciones que alteran los datos deben regresar algún valor, incluso si es un booleano que es actualmente siempre es cierto. Las funciones tienen una forma de eventual necesidad de devolver false