> >> It would be very easy for a maintenance developer to >re-initialize the value >> from a struct to an array somewhere in the middle of the >function. That >> would leave the <cfset var foo = structNew()> sitting there >waiting to >> confuse the next maintenance programmer who comes along. > >This is where management comes in. If there are practices and >procedures > that are a requirement it is up to the manager to make sure they are >met. Just because it is possible that this situation may pop up, it >doesn't mean you should ignore good practices.
This is true, but if you have good management practices it doesn't really matter how you approach the problem is so long as you're consistent in applying that approach. Unfortunately there are an ungodly number of projects that suffer from bad management at all levels. That's why I think it pays off to think about things from that point of view. If the management is good you don't have a problem, if the management is bad you are still in reasonably good shape. > > >> I'm not so sure that you can just glance at the top of a >function and know >> that the variables are going to be the type they are declared as. > >Again that is a management practice, it is up to your SLP. Again, that's relying on something that, in my experience at least, can't always be relied on. > >> CFML being the typeless language that it is, there is nothing to stop >> someone from changing the type of a variable as necessary. > >No, just like a stop sign, there is nothing making me stop, I do it >because that is the law. If you have the law in place with >consequences >that it will deture people from doing so. I stop at stop signs because I don't want to get flattened by a 40 tonne truck coming the other way. I don't just stop because the law tells me to. If the law is an ass I will probably ignore it if I think it makes sense to do so and a good many other people. The same applies to programming. If a developer can't see the value in a rule or regulation for coding they are more likely to ignore it, or at the least be careless about applying it. This comes back to the point about management. If you have a strong management team that gets a good team work ethic, you shouldn't have a problem with any of this. The difficulty comes in when the management is not good. > >> I tend to try to avoid doing things that could mislead >people (especially >> myself) in the future, so I use minimal commenting and very >rarely use the >> metadata attributes (displayname, hint) of any of the CFC >tags. That is >> another reason for initializing variables the way I do. > >If you have a standard practice and follow it, how can that be >confusing? > It can be confusing if your standard practice is not well documented or bears no resemblance to anything anyone else is doing. I have seen plenty of code where that applies. Spike ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
