Programming languages require code. And code can be written many different ways.
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.
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.
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.
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.
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
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
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.
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
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~!