August 7, 2007 at 6:17 am
>>If you check VB.NET or C# developers, they all write in good maintainable code
Being a .NET developer I can safely say that they do not all write in good maintainable code.
August 7, 2007 at 7:37 am
WHERE SvcTypeID IN (1, --Standalone Long Distance
2, --800 Service
3, --800 Pin
5, --Calling Card
1801 --Bundled Services
)
whether this is commented "properly" or not, I ask why these values are not in a table. I know the knee-jerk response is that it's easier/faster to use this construct, but how often has easier/faster for the developer been the long term growth solution? If these values do not exist in a control table, why not? If they ARE, then why is the developer hard-coding this list of services into the procedure? In an article on maintainable SQL, I would have expected hard-coding to be absolutely forbidden.
August 7, 2007 at 7:50 am
Just weighing in... good points in the article... I think some comments have their place, for example when you do something strange in the code for a good reason. An example I used recently is I had to create an in-line query that was nested twice. It was very unpleasant but it did the job. I commented it carefully so that developers who had to maintain the code could understand the thought process and why it was done like that.
My only pet-peeve regarding comments is when developers comment out reams of code and LEAVE IT IN THE PROGRAM. Trying to read and decipher that is a difficult task. It is even more pointless if you are using a version maintenance tool, such as SourceSafe. Just remove it, add a comment if you must indicating that code was removed and refer to SourceSafe. When I have to maintain a new program, I do 2 things, one is add whitespace, as article author indicated, and two is delete commented out code.
MikeZane
August 7, 2007 at 5:50 pm
Heh... I asked the same thing... and the answer is... crappola 3rd party software.
So, Mike, you never hardcode anything?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2007 at 11:59 am
nearly never. Absolutely never in a public example of maintainable code.
I forced myself to develop a habit of taking the minor pain up front to set up and use the DB for data rather than the major pain returning to the project months later and having to figure things out.
August 8, 2007 at 6:12 pm
That's actually a pretty good plan and I agree with that... nice to see someone to spend a little time up front to save wads later on.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply