Context-Driven Coding Standards

T-SQL Tuesday is the brainchild of Adam Machanic. It is a monthly blog party on the second Tuesday of each month. Everyone is welcome to participate. The current invitation (June 2022) is for T-SQL Tuesday #151: Coding Standards.

Prologue

Before I write what I think about the T-SQL coding rules today, I would like to confess my greatest and ongoing sympathy for this language. I created software with over 50 languages during my life, but none has shaped my feeling and understanding of good code as much as T-SQL.

This seems to be strange because so much cannot be done comfortably with T-SQL, and so much cannot be done meaningfully with it. So, as a programmer, shouldn't I dream of a language that will give me more possibilities to express intuition?

Maybe I should, but as Gilbert Keith Chesterton wrote beautifully somewhere, if God had an infinity to create the world, he would probably never create it, but because he gave himself seven days only, at the end of the week he could say that everything is very good (“And God saw everything that he had made. And they were very good.", Genesis 1, 31). You can think of T-SQL constraints as giving yourself the creation days limit on yourself. You can create very good things with T-SQL.

That is my statement of the great and ongoing sympathy for T-SQL.

But what do I think about T-SQL coding rules today? What would I say to the young Gerad, who starts digging into the matter of best practices, who tests various conventions, who follows discussions between rebels and imperialists, who has doubts about which side of the force is right?

The area of coding rules is a T-shirt of XXXL size, but I would say in the spirit of Domain-Driven Design: know your context. And depending on the context, apply one of the coding meta-rules.

Practice_ALL_conventionRules

In your pet projects - non-public, non-shared: practice all conventions.

Why?

First, to know all of these different rules and learn to apply them CONSISTENTLY. It is not easy, no matter what convention you choose.

Second, to build sympathy - or at least respect - for those who chose a different convention as the best in their case. You don't have to choose any convention as objectively the best. If you have learned something opposite, you are mistaken.

Each coding convention is a discipline at first. If you dislike a discipline, if you disrespect a discipline, then the choice of a particular convention is completely irrelevant.

ConsiderTheMainRuleConvention

In projects using ORM frameworks, such as the Entity Framework, where the Code First approach is dominant: consider using a convention applicable to the main language.

Why?

First, in order not to follow the convention by wasting time on unnecessary name transformations - which are name transformations to keep the convention. Do you have impression that the previous sentence is incomprehensible? That's it. Projects that maintain diplomatically separate naming conventions in the world of Java and Oracle, for example, are perceived by many programmers as incomprehensible, are developed more slowly and repaired more often for this very reason alone, so by design, they increase maintenance costs and give you little or nothing in return.

Second, to simplify so many operations: tool development, integration of subsystems, onboarding of new programmers, code searches and replacements, etc. Simplicity is one of the three main values of programming, do you remember?

"Consider" does not mean "give in". Sometimes separate conventions matter. But this cannot be taken as obvious, not requiring justification, in particular - economic justification.

HONOR_SQL_CONVENTIONS

For projects strictly related to databases, for SQL-centric projects: respect conventions of the pure SQL standard and conventions of Microsoft (with T-SQL example) used through technical documentation.

Why?

First, to efficiently use the habits of SQL programmers - and, you know the best, other-languages programmers, this is a special genre of programmers - to create code as efficiently as possible, especially with automatic code generation. Scaffolding tools made by SQL programmers are often made by themselves to improve productivity and usually work best with the SQL convention in mind.

Second, to avoid graphically inconsistent notation in the SQL syntax itself. Not to mention variable names! When I see SQL keywords written in PascalCase... no, this feeling is indescribable.

In the SQL standard, we have been using the convention of only uppercase or only lowercase letters and underscores for half a century - please respect this custom, other-languages programmers. This may not make sense in your modern language, but it makes sense to us. Don't make it difficult for us to copy the code from the documentation.

Keep Bounded Contexts

In multi-application projects: follow the convention depending on the particular application's domain.

This is perhaps the most difficult situation. On one hand, it does not differ from complete chaos and lack of design. On the other hand, it might imply that we are capitulating as designers and we don't want to make an effort for bringing harmony.

The charge of complete chaos and lack of design can be easily dismissed. Well, the design distinguishes between contexts, which have their own law and order and this is respected within the context. This is not chaos - it is a project that faithfully models reality.

The charge of capitulation as designers can be dismissed by a similar reference to humility: we recognize diversity, and we do not want to force the law and order of one context on another. We also accept the thesis that in more complex projects unification is almost always - "This is your choice, dear customer, choose what you want" - impossible to achieve, superfluous, killing productivity or too expensive to maintain. Benefits? Nothing obvious.

Epilogue

I could write a lot more on this topic, because I like the topic of T-SQL damn well, and feel the same about conventions or best practices, but Tuesday will be over soon. I have to give myself a boundary, and context to get the right effect. So I cross the line and the last paragraph is here. See you next time!