7/24/2015

Common Coding Techniques

Programming languages require code.  And code can be written many different ways.

Cryptic
Some people like to write code as simple as possible, using the fewest lines of code and character space.  While efficient, this can sometimes be difficult to maintain.  And understand.  Perhaps they combined 9 lines of code into a single line.  Maybe the variables names are not descriptive.  For example:


Declare @a nvarchar(6)
Declare @b nvarchar(25)

Uh, what's @a signify?  And @b? Who knows.  Job security.

Intuitive Code
There's lot of code out there, where you know the programmer went out of their way to make the code complex.  Because when you are the person who has to maintain it, the code is not intuitive.  If you've spent time in the trenches working as a maintenance coder, you know the importance of writing code that people can understand.  Maybe back in 1968, where the programmer only had 2kb of ram for the entire program, writing super efficient code was valuable.  Now a days, code should be written with the maintenance coder in mind.

Comments
And what about comments.  Most code I've seen has limited to no comments or comments that made sense at one time but no longer valid and only serve to confuse the next person.  There should be a flag in the IDE to mandate good coding practices.  Perhaps set it to No Comments, Limited Comments, Required Comments and Shrink Wrap Comments.  And each org can mandate the level required.

Camel Case
When writing code, it should be legible for the next person.  So deciding on a language preference, it's good to pick one and stick with it.  In T-SQL, there are so many ways to write the code.  For example:

[Current Price] [bit] NULL,
[CURRENT PRICE] [bit] NULL,
[current price] [bit] NULL,
[current_price] [bit] NULL,
[CURRENT_PRICE] [bit] NULL, 

[CurrentPrice] [bit] NULL,
[currentprice] [bit] NULL, 
[CURRENTPRICE] [bit] NULL, 
[current-price] [bit] NULL,
[CURRENT-PRICE] [bit] NULL,

You get the point.  Many ways to confuse the next developer and make their lives more difficult.  If that's the intent.

Consistency
Back in the 1990's when I was learning to code, the Senior Developer made it very clear, on coding standards and sticking to them.  He said you should be able to read the code like a book, following the plot, as you step through the code.

At the time, I did another no-no.  I was learning to code in Visual Basic, so I tried different approaches to conquering the same thing.  For example, in one place, I would use a Class.  In another, I used a User Defined Function.  In another place, I did something different.  He made sure I knew about the error and not to do it again.

Run On Code
You've heard of the run on sentence.  Goes on forever.  It's possible to jam too much code into a single block of code.  Like a Stored Procedure that goes to 4000+ lines.  Sometimes it's good practice to break the code into mini blocks.

Code that Calls Code that Calls Code
There are ways to make code extremely difficult.  One technique, is to create code that calls code that calls code.  A classic example is a View in SQL that calls a View that calls a View, which gets called by Stored Procedure, on a Linked Server.  Tough to track the code down and figure out what's happening where.  Need Triple-A road map sometimes.

Writing Bugs
There's probably a few bugs in every piece of software, undetected.  The most bizarre bug I ever troubleshot was in a CASE statement, it went on forever and checked for endless combinations.  In one, it was checking an "O", as in Oh.  Stepping through the code, it wasn't falling into the CASE statement as expected.  Looking more closely, it turned out the developer used a Zero 0 instead of an Oh O.  Obviously they look the same.  Gotcha!  That was a good undetected land mine.

Run on Formulas
This one is significant.  If you've ever had to translate spaghetti code from Excel formulas to T-SQL, you know what this one is all about.  I had one project, where an Excel notebook had 10 tabs.  Each tab was considered one report.  Except each tab had 10 report within.  So there were actually 100+ reports, billed as 10.  For example, one report had some fields.  One of those fields called another tab in the workbook.  That tab had some funky logic, which called another tab.  Which called another tab.  Which got produced from an Access database.  And the Access database had a 15 step process to prep the data.  Which it pulled from the source database, SQL Server.  This was an absolute nightmare.  Job security for the author, none the less.  I still wake up in the middle of the night sometimes dreaming I'm stuck somewhere along the chain of logic from this code.  Perhaps in time, it will get better.

So there you have it.  Some pieces of information on coding.  Perhaps someone can relate to one of these topics.

Thanks for reading~!

No comments:

Post a Comment

Root Cause Analysis