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.
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?
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.
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.
----------------------------------------------------------
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]
