Conventions

Patterns/Philosophies I've used

MSTestv2

It kinda works. I try to have at least one test per function. That's always the first goal. Eventually get IntelliTest working.

Regular comments instead of Java doc.

Those XML blocks are a bit bloated. I'm waiting for the JSON version of XML java-doc.

Upper-case character type tags

So "C" on the end of functions that take a character or string of characters as inputs. Just enough information for me as the regular user to distinguish between similar functions between ones that deal with characters and treat strings as character arrays, ones that deal with strings, and ones that deal with matches. I might add "I" for ones that deal with integers, since SQLCLR doesn't support type overloading.

Title-case method names

Verb-first method names

Not always, but when it makes sense. IsNull, for instance.  StringExtract functions don't follow this, since it would always be "Get-" or "Extract-".  Repetitive, and leaving the verb off makes it more like command English.  You might say "There!" instead of "You, sit there".

Hungarian notation for class names

I wanted to see all the string classes together. So StringExtract, StringTest, StringReduce, etc.

Over functioning

I created an IsEmpty and IsNull and IsNullOrWhiteSpace, etc, since I see these things as documentational, rather than "string.Length != 0" or "string != null".

Mirror SQL Server behavior

So if you ask a function "How many characters are in a null string", it returns null, rather than 0.  The rules of SQL are null inputs are null outputs.  However, I do not follow this for search strings (markers.)  If you ask, "How many nulls in the string 'ABCD'", I throw an exception.

Throws exceptions

Throw early, debug early, rather than (you know who) avoid or discard exception cases so the downstream developer gets stuck dealing with it.

Clean up messages from VS

I used to ignore the message pane in VS Error List.  But it is very educational, and results in cleaner code. The biggest issue in debugging is with the brain's insistence on processing all input when reading.  You could skim, but then you would miss the bug you're looking for.  So your brain gets hung over and over when reading down a document, like "string.ToString()."  Not an error, but a squiggly, and a trip-up when scanning.  The more you take out, the more your brain can automate and slip down to real errors.  Also why I say "name.IsNotNull()" rather than "name != null).

Standardized argument names

Not consistently, but at least I try to have "input", "marker", "pattern", and "sep".  One great benefit is that cut and paste validation code can be copied down.  input can be null and return null.  marker can never be null, or pattern.  marker can be non-empty whitespace but pattern cannot. "sep" is a bit of an awkwardness since it is pretty much a marker, too. Hmmmm.   Note that SQLCLR functions on the SQL side do not care one iota about the function's argument names, just types.

Source Control

git, github, free

Stage single files instead of all at once

I hate reading history in github and every file has the same comment on it.

Compare with unmodified

    Look before committing!  This gives you an "oh yeah" moment.

Document all commits

    And document them better.  For some things like typos, then "typo" or "spelling" is fine.

Function documentation includes examples

I can't remember how I would call such and such function.

Try new things

Pushes the boundaries, so don't expect code that doesn't do something risky.  Read the code before using.  I use it in DBA work, but for actual production I would have to think very carefully.  Perhaps that would be a subset.

Bleeding Edge

At least for some things.

SQL Server 2019 15.0.4043.16

I know probably no one is using it, but for local databases running DBA scripts against remote servers, this is really reliable.

Input validation

Heavily!  I don't care about performance affect. Maintenance cost is a bigger deal than performance cost!