I was catching up on some long overdue reading and this article from a Django newsletter caught my eye. This reminded of a recent idea for a similar file to live in a codebase.

This file is called The purpose of this file is to describe the patterns and conventions that exist in a project that may tie to the architecture, but are too fine grained to include in a high-level document. Examples would include database field name conventions and relevant code to support them, method names on classes, where business logic should live or class mixins that are available.

The event that birthed this idea was me inheriting a codebase and creating a new model with a field named is_active, this is reasonable, but I later realised that previous developers had named fields is_available and had put in extra work with a BaseManager and Queryset for the functionality Essentially we want to surface patterns that exist across the codebase to ensure the codebase remains consistent across time and developers.

While I write this I reminded of another a recent article from Luke Plant where he addresses the same concerns in regard to DateTime Fields using the checks framework in Django. This file could be seen as an language agnostic version of that or a first step towards using a similar method that he outlines.