LiveDocs Comments - wtg - public - coding_standards - goodpractice.html

wtg/public/coding_standards/goodpractice.html

SeanCorfield — 2004-08-06T18:54:00

Extending global.cfc is not good practice - CFC A should only extend CFC B if the logical relationship "A is-a B" holds true. Since global.cfc does not represent any sort of logical entity, the "is-a" relationship cannot hold.

You have several options for global variables depending on whether they represent truly static values (use a configuration file of some sort - either XML or a 'properties' file since CF can read both of those easily) or dynamic values.

For dynamic values, you can still use a CFC but it is just a 'service' CFC with methods to get the desired global value. Code that uses that CFC can either simply cfinvoke the method or, if you wish, construct an instance of the CFC and call multiple methods.

wtg/public/coding_standards/goodpractice.html

yitian — 2004-08-04T19:16:48

May I know what is the best way to define global variables in CFCs?

Currently I have a global.cfc for each project to hold the global variables, and other CFCs will extend global.cfc if they need the variables. Your article recommends every contructor to have a init(). Does it imply for my global.cfc as well, since it doesn't contains any function, only variables.

My CFCs are Web services, and they don't store at the same place with other CFMs, so I suppose storing global variables in Application.cfm is not a good choice.

I'm having quite a number of projects on the server, so I suppose declaring global variables for each project in component.cfc is not very suitable also, since different projects use different sets of variables.

wtg/public/coding_standards/goodpractice.html

SeanCorfield — 2004-06-21T17:22:55

In a language that silently converts numeric values to boolean when the context requires it, you have the situation that zero converts to false but any non-zero value converts to true. However, while false converts to zero for a numeric comparison (allowing you to test eq false), true converts to 1 which will not be equal to an arbitrary numeric value.

That becomes a trap when you see things like if ( compare(s1,s2) ) and think you can do if ( compare(s1,s2) eq true ) - which only yields true when s1 is greater than s2 even tho' the first form yields true for s1 less than or greater than s2.

Therefore it is simply much safer to never test values equal to true or false and let the implied boolean context 'do the right thing'.

wtg/public/coding_standards/goodpractice.html

grantmr — 2004-05-30T17:34:38

this first point about booleans - why is it bad practict to provide the expected value - i realise that it's redundant, but is there any danger is doing so?