Today I’m thinking about a “coding standards” document and what should be included in it. Linters cover most rules except for casing… scratch that, eslint has a calcase rule. I like to case database tables and fields one way (snake_case), code a different way (often camelCase but depends on the language), and th there’s also things like url parameters other things that should follow a consistent pattern. Other topics (brainstorming here) to include are DRY (more and less), file size, logging patterns, commenting (or lack thereof), error handling, uri testing, code coverage standards. I’ll be thinking of more later. Some of these things can be enforced with Draconian linter policies, but I tend to like to put just the big things in linter rules (e.g. no unused variables) and leave at least a little creative freedom to the devs. It’s fun to be able to look at code and know who wrote it without looking at git history/blame to find out - since the mark/style of a human remains.