Naming and Contract Alignment
Detects method renames where the new CRUD verb semantically contradicts the old verb, signaling an intent mismatch.
Why this rule exists
Renaming Delete to Get keeps the old behavior but advertises a new contract. Callers see Get and assume safety; the method still deletes. Rename refactors must match new behavior, not just new vocabulary.
Code example
- public void DeleteOrder(int id) { _repo.Remove(id); _repo.Save(); }
+ public void GetOrder(int id) { _repo.Remove(id); _repo.Save(); }- public void DeleteOrder(int id) { _repo.Remove(id); _repo.Save(); }
+ public Order GetOrder(int id) => _repo.Find(id);
+ public void DeleteOrder(int id) { _repo.Remove(id); _repo.Save(); }Configuration
Disable or adjust the severity of this rule in .gauntletci.json:
{
"rules": {
"GCI0047": { "enabled": true, "severity": "Info" }
}
}See Configuration for the full schema.
Related rules
Discussed in
Implemented in src/GauntletCI.Core/Rules/Implementations/GCI0047_*.cs.
Eric Cogen -- Founder, GauntletCI
Twenty years in .NET production. Most of those years, the bugs that hurt me were not the ones tests caught. They were the assumptions I did not know I was making: a removed guard clause, a renamed method that still did the old thing, a catch {} that turned a page into a silent dashboard lie. GauntletCI is the checklist I wish I had run before every commit. It runs the rules I learned the hard way, so you do not have to.