Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Are Coding Conventions and Why Leave Them to Tools, Not People? Sources, Levels and Team Decisions
The value of a coding convention comes not from the rule itself but from it being settled and enforced by a tool: in Bookstore a one-line discount change was buried in a 55-line diff by editor settings, and .editorconfig plus dotnet format brought it back to one line. The post covers the formatting, style, naming and architecture levels, choosing a source and making the team decision once and recording it.
Encoding C# Conventions in .editorconfig: Code-Style Options, Naming Rules and Enforcing on Build
A naming rule's own severity line is not read on build; to enforce the rules in dotnet build you need dotnet_diagnostic.IDE1006.severity alongside EnforceCodeStyleInBuild. The post covers the .editorconfig hierarchy, the IDE rule IDs behind code-style options, the symbols-style-severity triple of naming rules, a test folder override, how category-Style enforces defaults you never chose, and rules that run only in the IDE, all with real build output.
Choosing a C# Formatter: dotnet format or CSharpier? Giving Each Rule a Single Owner
When two formatters own the same rule the loop never ends: on a 1,000-file Bookstore solution, dotnet format found 6,002 problems in CSharpier's output and CSharpier found 1,001 unformatted files in dotnet format's. The fix is to give whitespace to CSharpier and style to the analyzer; the post compares both tools' output and timings, shows why turning off IDE0055 is not enough, and pins the version with a dotnet tool manifest.
Conventions in Angular and TypeScript: The Style Guide, Prettier and Dividing Responsibility with ESLint
In an Angular project formatting belongs to Prettier, naming and selector rules to ESLint, and eslint-config-prettier draws the line between them: without it, two copied @stylistic rules produced 110 errors on Prettier-formatted code. The post covers the Angular 22 Style Guide's decisions, keeping suffixed names in older projects, Prettier flagging 7 files in a fresh project, the naming-convention rule and ESLint 10 ignoring .eslintrc.
Automating the Rules: Pre-Commit Hooks, CI Gates, Gradual Adoption in Legacy Codebases and .git-blame-ignore-revs
A pre-commit hook gives fast feedback but is skipped by --no-verify; the only place that stops a convention violation before main is a required CI check. The post shows formatting only staged files with Husky.Net and lint-staged, CI steps that name the fix command, choosing between touched files and a big bang in legacy code, .git-blame-ignore-revs, updating open PRs without conflicts and a suppression policy, all with real output.