> >> 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. > >Agreed > >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. > >Whether management is good or bad, it is a bad practice to change a >variables type mid stream. So I'm not going to not code around >the fact >of not formally setting a variable to it's type on initialization just >because it's possible that one ignores good practices and set >procedures.
Agreed. > >Take an organization such as NASA. NASA has methodologies of writing >software. That would include a requirement that all >programmers working >on the project adhere to the standards set my SEL. If a programmer >chooses to ignore a procedure I'm sure SEL's framework for the >application in question does not program for the case where a rouge >programmer thinks the procedures stink. Rather the code goes through >SATC to verify the quality of the project. > >Just because SATC could possibly fail to do their jobs >correctly doesn't > mean that SEL should allow for a rouge programmer to do what they >will. If they where to do that, how could procedures ever be defined? Requiring that programmers stick to a standard and enforcing that requirement will always limit the sort of problems you encounter. I am all too familiar with projects and companies who don't do that. I think in either case it's a good idea to try to ensure that you design the practices and procedures so as to minimize the both the likelihood and impact of failure to follow the procedures be it through carelessness, malice, or simple human error. The specific case of a variable changing type mid-stream is probably not a a good example of where this can have a big impact, but I think the principle still holds. > > >> 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. > >Most of the time a law is a law for a reason. Just because you may not >understand or dislike the law doesn't mean that it shouldn't >be followed. I think we both agree with this. > >> 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. > >That is true, however just because NASA may have their own >methodologies, doesn't mean that it is wrong just because it is not a >standard in larger development arena. > >For example, I know that NASA on certain projects has thrown out the >possibility of adopting a known standard from the rest of the >community >because either it was lacking in completeness or was >incompetent. And as >such they have written their own SLP that may or may not resemble any >known practice outside of NASA. That does not make it any less >viable a >practice and be ignored just because a uniformed programmer doesn't >agree with it and thinks a better well known standard should >be adopted. Yes, but in the case of NASA I'd bet that the standard is well documented and that they have procedures in place to ensure that it is followed. ---------------------------------------------------------- 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]
