December 3, 2020 at 12:00 am
Comments posted to this topic are about the item Catching Minor Issues
December 3, 2020 at 3:43 pm
Shameless plug and praise here for SQLServerCentral… The majority of my coding standards and practices are derived from reading and applying the concepts from the content of SQLServerCentral articles and forum posts. It has served my career (and sanity) well to follow the advice found here.
This is another great example of exactly that. It was a decade or more ago that an article here convinced me to stop using SELECT *. The issues that happen when column order changes were the big one for me since you don't get a hard error just misaligned values that don't necessarily raise an error but lead to incorrect data. For the same reasoning of not relying on column order and explicitly specifying our column lists I do the same thing with parameters.
Another great piece of advice and a coding standard everyone would benefit from implementing. Thanks Steve!
-
December 4, 2020 at 2:43 pm
I don't use named parameters, although C# does support them. We've adopted using what's called Summary comments to decorate methods or properties. This is done by starting a comment before a method/property using 3 "/". Visual Studio will automatically put in code before the method/property like this:
/// <summary>DoWork is a method in the TestClass class.
/// <para>Here's how you could make a second paragraph in a description.
/// <see cref="System.Console.WriteLine(System.String)"/> for information about output statements.</para>
/// <seealso cref="TestClass.Main"/>
/// </summary>
/// <param name="Int1"></param>
public static void DoWork(int Int1)
{
}
Kindest Regards, Rod Connect with me on LinkedIn.
December 4, 2020 at 2:51 pm
(Strange, the editor for this forum won't let me enter anything after the C# code I entered. So, to continue...)
I do this to all public methods. Private methods, I figure, can be found in the file you're editing (or another file if it's a partial class, but that's a different topic).
Anyway, this is a great way to let other developers know what a method expects. As they're editing a file, if they use your object's method, in Visual Studio, it prompts with the description of the method and the parameters. Just remember to fill out that information.
This is a significant help! I've come across some older code here where whoever just used single letter parameter names:
MakeColor(r, g, b, a)
Yeah, likely you'll know what that means, but not necessarily.
Kindest Regards, Rod Connect with me on LinkedIn.
December 5, 2020 at 3:57 pm
"Minor Issues"??? A multi-million dollar rocket crashing is NOT a "Minor Issue"! 😀 Neither is using a space vehicle for a planetary drill because of a difference in measuring systems nor is something as "simple" as passing parameters backwards.
This is why that, before QA, we put our code through Unit Testing, a peer review AND a DBA review. Is it going to slow you down??? It will seem so at the beginning but the amount of rework necessary to discover where the problem is, fix it, and retest it will actually save huge amounts of time, not to mention your code giving your company a serious black eye if it makes it to the customer.
If you want to prevent such a waste of time and total embarrassment (possible costing you current and future customers), you only need to "Do it right the first time" with no exceptions. Simple peer reviews and DBA reviews can prevent a whole lot of that and so can "Unit Testing". It takes a little extra time on the front to do it but saves huge amounts of time in the release cycle.
Slowdown a bit and "Do it right the first time all the time". The payback will be absolutely incredible.
I know what you're getting ready to do... you're getting ready to make some excuses based on schedule. Stop making such ridiculous excuses. It doesn't take much extra time to ensure you're doing it right but just a couple of "oops" will cost you shedloads of time and possibly cause you to miss the schedule by a whole lot. "If it's worth doing, it's worth doing right".
And, yeah... that also means you have to "Do it by the book". Most companies have no such book and need to document just exactly what needs to be done during the SDLC and then it has to be ENFORCED!
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply