---
id: KB-ET-015
url: https://app.codecontract.io/help/your-workspace/naming-things-so-you-can-find-them
idioma: en
categoria: espacio-de-trabajo
subcategoria: contactos
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-ET-004, KB-ET-006]
citadoPor: [KB-ET-018]
---

# Naming things so you can find them

_Three naming rules worth more than any folder structure._

**Responde a:** how to name files · file naming convention · organising project names · criteria for naming documents

People argue a lot about how to organise folders and hardly at all about how to name things, when it should be the other way round: with good names you find everything even with a mediocre structure, and with bad names no structure saves you.

## The three rules

1. **Start with what distinguishes it** — If you search by client, the client goes first. If by site, the site.
2. **Include the identifier people actually use** — The order number, the registration, the site code. The one said out loud, not a new one.
3. **And the date in sortable format** — 2026-08 sorts properly; August 2026 does not. Only if the date matters.

> [!IMPORTANT]
> The second pays off most and is broken most. If in the office the job is "the port one" and in the system it is "EXP-2026-0448", there are two vocabularies and someone must translate each time. Include both: nobody ever regretted a slightly longer name.

## What not to include

| Not this | Why |
| --- | --- |
| "final", "definitive", "good" | A "final2" always appears |
| The author's initials | It stops meaning anything when they leave |
| Abbreviations only one department understands | Nobody else will ever search for them |
| The version, if the system already tracks it | It duplicates information and drifts out of sync |

> [!WARNING]
> The first row seems trivial and is not: "contract_final_v3_reviewed.pdf" lives alongside "contract_final_good.pdf" and nobody knows which governs. If there are versions, mark them as versions; the name is not the place.

## And with contacts

**En corto**

- The full legal name, not just the trading nickname.
- The tax identifier, the only thing that does not change.
- And one record per company, even with several branches.

Duplicate contacts are the number one cause of "I can't find it", and they almost always come from writing the same name three different ways.

> [!NOTE]
> None of this is needed if you search inside documents, which works fine with bad names. But names appear in listings, and that is where the time actually goes.

**Should old material be renamed?**

No. Apply it to new material; old material is found by content.

**What if each department wants its own?**

Agree only on the shared identifier; the rest can vary.

**Are automatic codes any good?**

Yes, but alongside the human name: a bare code forces translation.

## Ejemplos

**A team has three records for the same supplier, spelled three ways.**

- Unifies by tax identifier and uses the full legal name

→ Searches return one record and the supplier's history stops being split.

**Files are named with acronyms only one person understands.**

- Uses names anyone on the team understands

→ Finding stops depending on one person.

**Two files have nearly identical names.**

- Adds what distinguishes them to the name

→ Nobody works on the wrong one.

**The name includes a date in three different formats.**

- Agrees one format and applies it

→ Alphabetical order becomes useful.

**A search by name returns nothing.**

- Searches by content rather than name

→ The name stops being the only route.

**Each person names things their own way.**

- Agrees the convention and writes it down

→ The archive is readable for everyone.