Estás a punto de enviarle un archivo a un cliente y la carpeta te ofrece final_v2, final_FINAL y final-nuevo. Abres uno, luego otro, y acabas escribiéndole a un compañero para preguntarle cuál fue el que salió. El trabajo está hecho. Encontrarlo es el problema.
Eso es justo lo que resuelven unas buenas convenciones de nomenclatura de archivos. Un buen nombre le dice a un desconocido qué es un archivo, a qué pertenece y si está actualizado, sin que nadie tenga que abrirlo. Además, tiene que sobrevivir al viaje a otro ordenador, a una unidad compartida o a un sistema operativo distinto.
La plantilla de nombres que cualquier equipo puede copiar
Empieza con este nombre:
NORTE-2026-03-14_concepto-logotipo-marca_v03_final.psd
Léelo de izquierda a derecha. NORTE es el proyecto. 2026-03-14 es la fecha. concepto-logotipo-marca describe el contenido. v03 es la versión. final es el estado. .psd es la extensión que añadió la aplicación.
El orden importa. Pon primero el elemento más estable, normalmente el código del proyecto, para que una carpeta ordenada agrupe el trabajo por proyecto y después por fecha. Si empiezas por el descriptor, los archivos de proyectos distintos se esparcen por la lista y es la búsqueda la que hace el trabajo que tendría que haber hecho el nombre.
Los seis elementos en orden
| Elemento | Patrón | Valor de ejemplo | Regla |
|---|---|---|---|
| Código de proyecto | 3-6 letras mayúsculas o dígitos | ACME | Fijo durante toda la vida del proyecto |
| Fecha | AAAA-MM-DD | 2026-03-14 | Fecha de creación o de entrega, según indique la guía |
| Descriptor | 2-4 palabras en minúscula unidas por guiones | concepto-logotipo-marca | Describe el contenido, no el estado |
| Versión | v + dos dígitos | v03 | Aumenta en cada iteración guardada que se envía a revisión |
| Estado | borrador, revision o final | final | Solo en los entregables |
| Extensión | Sin cambios respecto a la aplicación | .psd | Solo un punto final |
Hay detalles en los que la gente suele tropezar. Tu descriptor debe decir qué hay dentro, no lo terminado que está. "concepto-logotipo-marca" funciona. "version-nueva" no, porque lo de nueva deja de ser verdad mañana. Eso lo expresa el estado, y solo si lo limitas a una lista corta. En cuanto alguien añade "final-casi" o "aprobado-quizas", el estado deja de poder buscarse.
La versión es otra cosa distinta. Un archivo puede ser v03 y seguir siendo un borrador, o ser v07 y estar ya en final. Mantén esas ideas en casillas diferentes y nunca necesitarás nombres como final2 o final-de-verdad-final.
Si además pones nombre a productos o funciones, la guía de Sprello sobre nombres de producto es un buen complemento, porque aborda la misma disciplina desde el lado del nombre: etiquetas cortas, coherentes y fáciles de entender para alguien ajeno.
La prueba del desconocido
Antes de guardar, hazte tres preguntas.
- ¿Qué es esto? El descriptor debería responder sin abrir el archivo.
- ¿A qué proyecto pertenece? El código debería verse claro de un vistazo.
- ¿Es la versión actual? La versión y el estado deberían zanjarlo.
No necesitas los seis elementos siempre. Una foto personal quizá solo necesite fecha y descriptor. Lo que sí necesitas es el mismo orden, siempre, para que los elementos que faltan no descoloquen a todos los demás.
Por qué las convenciones de nombres fallan en la práctica
A muchos grupos no les falta esfuerzo. Les falta un acuerdo que sobreviva a una semana movida.
Piensa en un archivador con cajones sin etiquetar. Todos los papeles están ahí dentro, en alguna parte, pero encontrar uno significa abrir cada sobre. Una carpeta compartida llena de "presentación", "presentación nueva" y "presentación marzo" funciona igual. Los archivos existen. El sistema para recuperarlos, no.
Dos tipos de fallo causan la mayor parte del desorden.
Los nombres se desvían. Una persona escribe las fechas como 14-03-2026, otra como 2026-03-14 y una tercera se las salta cuando hay prisa. En un mes, el mismo proyecto usa tres formatos de fecha y dos esquemas de versión, y ordenar deja de tener sentido.
Los nombres solo tienen sentido para quien los puso. "Borrador para Sara" está clarísimo el día que lo guardas. Seis meses después, cuando Sara ha cambiado de equipo, no le dice nada a nadie. Tu yo del futuro también es un desconocido en esta historia. Si no eres capaz de ubicar un archivo un año después, el nombre falló, aunque lo escribieras tú.
No es un problema raro. En un estudio multisectorial de 2026 publicado por Daniel Coward en LinkedIn que abarcó más de 200 empresas y unos 10 000 archivos, el 73 % de los nombres de archivo tenía problemas como formatos de fecha incoherentes, versiones poco claras o falta de contexto.
Lo que una convención que funciona arregla de verdad
- Facilidad para encontrar: busca un código de proyecto y aparecen todos los archivos relacionados, incluso en carpetas distintas.
- Orden: una lista en vista de lista se lee en orden de proyecto y cronológico sin reorganizar nada a mano.
- Traspasos: diseñadores, desarrolladores, tutores y clientes pueden identificar el archivo correcto sin preguntar.
La nomenclatura forma parte de un sistema de organización más amplio, y los equipos que gestionan grandes bibliotecas de recursos encontrarán ideas útiles en cómo construir una taxonomía escalable de activos digitales, que explica cómo aguantan las categorías y las etiquetas a medida que crecen las colecciones.
Una convención solo es tan buena como el acuerdo del equipo para usarla. Una plantilla perfecta metida en un documento que nadie lee no cambia nada, así que el proceso de creación tiene que ir generando ese acuerdo por el camino.
Cómo crear tu convención en seis pasos
Este es el proceso completo en una sola página, antes de repasarlo paso a paso.
Define el propósito. Apunta las tres preguntas a las que debe poder responder rápido cada archivo, normalmente qué es, a qué proyecto pertenece y qué versión es. Las reglas sin propósito se abandonan la primera vez que aprieta un plazo, porque nadie sabe explicar por qué importan.
Elige entre cuatro y seis elementos y fija su orden. Escoge entre código de proyecto, fecha, descriptor, versión, estado y rol. El error que hay que evitar es añadir elementos que nadie va a rellenar. Si tu equipo no va a anotar la ubicación o un contacto del cliente en cada archivo, déjalo fuera, porque un elemento que queda vacío la mitad de las veces rompe el patrón para todos.
Fija separadores y mayúsculas. Usa guiones entre palabras dentro de un mismo elemento y guiones bajos entre grupos de elementos, minúsculas en todo salvo en los códigos de proyecto, y sin espacios. Los espacios rompen los scripts de línea de comandos y algunos enlaces web, y hacen más difícil seleccionar el nombre con doble clic. Elige un esquema y no dejes que cada uno mezcle guiones y guiones bajos a su aire.
Fija las reglas de fecha y versión. Las fechas son AAAA-MM-DD, las versiones empiezan en v01, y defines una sola vez si la fecha es la de creación o la de entrega. Esa única definición evita una discusión silenciosa que, si no, dura años, con la mitad del equipo fechando por creación y la otra mitad por entrega.
Mira estos pasos aplicados en un breve tutorial antes de redactar tu propia guía.
Escribe una guía de una página. Incluye cinco ejemplos buenos y cinco malos, además de una regla para las excepciones, como los archivos antiguos que no vas a renombrar. Que quepa en una página. Un estándar de doce páginas da a entender que ponerle nombre a las cosas es burocracia, y la gente esquiva la burocracia. Fija esa página donde se guardan los archivos, no en una carpeta de políticas que nadie abre.
Haz un piloto de dos semanas en un proyecto activo. Después, revisa las dos o tres reglas que más se incumplieron. Si te saltas el piloto, acabarás con reglas que nadie usa, porque descubrirás demasiado tarde que hay un elemento difícil de aportar en el momento de guardar.
Cuando una regla se sigue incumpliendo durante el piloto, tómalo como información sobre la regla, no como desidia del equipo.
Cómo sabrás que funciona
Las listas ordenadas se leen como una línea de tiempo. Cualquiera del equipo encuentra el último archivo final en menos de diez segundos, y los recién llegados pueden poner bien los nombres desde el primer día usando solo la página de la guía.
Formatos de fecha y versión que se ordenan bien
Abre una carpeta con 3-4-26, 2-11-26 y 10-3-26. En vista de lista se ordenan por su primer carácter, así que 10-3-26 aparece antes que 2-11-26 y la cronología queda hecha un lío. Ahora añade las versiones v1, v10 y v2, y el ordenador coloca v10 antes que v2, porque el orden de texto lee carácter a carácter y "1" va antes que "2".
Ambos problemas parecen descuido. Son problemas de formato, y tienen arreglos mecánicos.
Por qué la fecha empieza por el año
AAAA-MM-DD se ordena cronológicamente en cualquier gestor de archivos porque la unidad más grande va primero y cada unidad tiene un ancho fijo. DD-MM-AAAA ordena por día, así que todos los días 1 de cada mes se agrupan. Y 3-4-26 trae un segundo problema: es ambiguo entre el 4 de marzo y el 3 de abril según dónde viva quien lo lee, y un año de dos dígitos deja el siglo a la imaginación.
La propia guía de Microsoft llega a la misma conclusión para el trabajo multiplataforma. La documentación de Microsoft sobre nombres de archivo respalda formatos que empiezan por la fecha, como AAAA-MM-DD, para mejorar el orden léxico, junto con códigos de proyecto y de versión estables que reducen la ambigüedad en el procesamiento por lotes.
Mantén separadas la fecha y la versión
La fecha registra cuándo se hizo o se entregó un archivo. La versión registra de qué iteración del trabajo se trata. Son datos distintos, así que dos archivos del mismo día pueden diferir en versión, y una misma versión puede volver a entregarse en otra fecha. Si los fusionas, pierdes uno de los dos.
El relleno con ceros es lo que hace que las versiones se ordenen. Escribe todos los números con dos dígitos, de v01 a v99, para que v02 quede antes que v10. Si está claro que un proyecto va a pasar de las noventa y nueve iteraciones, empieza directamente en v001 en lugar de cambiar a mitad de camino.
Los códigos estables también ayudan a los scripts. Un código de proyecto fijo y un conjunto pequeño de palabras de estado permiten que una herramienta por lotes reconozca los archivos con fiabilidad, y por eso merece la pena leer una guía sobre cómo renombrar archivos por lotes en Mac una vez que tu patrón esté definido. Los equipos que trabajan con muchos datos reconocerán la misma disciplina en los enfoques para gestionar versiones de datos de robótica, donde un código de versión tiene que ser inequívoco a lo largo de muchas ejecuciones automáticas.
Si trabajáis en zonas horarias distintas, fecha la entrega en la zona horaria del propio equipo y deja esa regla escrita en la guía, de modo que un archivo enviado cerca de la medianoche tenga una única fecha acordada.
| Error | Por qué falla | Formato mejor |
|---|---|---|
| Fechas escritas como 3-4-26 | Año y día se ordenan al revés | 2026-04-03 |
| Versiones como v1, v10, v2 | El orden de texto pone v10 antes que v2 | v01, v02, v10 |
| final, final2, FINAL-nuevo | Sin orden y sin un último archivo claro | v04 más estado final |
| Fecha del último guardado usada como fecha de entrega | Cada nuevo guardado cambia la fecha | Fecha de entrega en el nombre, no la de guardado |
| Orden día-mes mezclado en el equipo | Fechas como 03-04 son ambiguas | AAAA-MM-DD en todo el equipo |
Termina con una regla que evita la inflación de versiones. Sube la versión en cualquier guardado que envíes a otra persona, no en cada guardado que hagas. Tus guardados de trabajo locales son asunto tuyo. El número de versión es una herramienta de comunicación para los demás.
Caracteres, acentos y límites de longitud que rompen las transferencias
Hay una suposición muy común que conviene cuestionar. Si tu Mac acepta un nombre, el nombre está bien.
No es así. El sistema más estricto de tu flujo de trabajo marca el límite, no el Mac que creó el archivo. Un nombre perfectamente legal en casa puede no copiarse a un volumen de Windows, ser renombrado por un servicio de sincronización o quedar inaccesible dentro de un árbol de carpetas profundo. La mayoría de los consejos sobre nombres se quedan en la legibilidad. El riesgo de la transferencia es la parte que hace perder archivos.
| Restricción | Dónde falla | Práctica segura |
|---|---|---|
| Caracteres reservados: < > : comillas dobles / \ | * | Volúmenes de Windows, sincronización en la nube, archivos zip | Solo letras, dígitos, guiones y guiones bajos |
| Límite de 255 caracteres por nombre | Descriptores largos en Windows y recursos de red | Mantén cada nombre muy por debajo de 255 bytes |
| Límite de 260 caracteres de ruta (MAX_PATH) | Árboles de carpetas profundos copiados a Windows | Limita la profundidad de carpetas a unos cuatro niveles |
| Nombres de dispositivo reservados CON, PRN, AUX, NUL | Equipos con Windows | No los uses nunca como nombre de archivo o carpeta |
| Punto o espacio al final | Windows los elimina o los rechaza | Quítalos antes de guardar |
| Acentos descompuestos (NFD) | Scripts de Linux, Git y herramientas de sincronización | Normaliza a NFC y comprueba la longitud en bytes |
| Longitud superior a 255 bytes | Nombres con acentos tras la transferencia | Comprueba el recuento de bytes en la ruta de transferencia real |
El problema de los acentos, en cristiano
Una letra con acento puede almacenarse de dos maneras. Puede ser un único carácter precompuesto, o una letra base más una marca combinada aparte. En pantalla se ven idénticas.
Como explica la guía de Unicode en nombres de archivo, macOS suele exponer nombres descompuestos, de tipo NFD, mientras que los entornos Linux suelen usar NFC o dejan la normalización tal cual. Esa discrepancia puede crear nombres que parecen duplicados, comparaciones que fallan, scripts rotos o conflictos de sincronización, aunque los usuarios vean exactamente el mismo texto.
Hay un segundo detalle. La longitud del nombre se mide en bytes y no en caracteres visibles, y descomponer los caracteres con acento aumenta el recuento de bytes. Un nombre que parece quedar por debajo del límite puede superar el límite de 255 bytes por componente tras una transferencia o un procesamiento. Por eso contar caracteres en el Finder da una falsa tranquilidad.
El compromiso sincero de los nombres solo ASCII
Restringirlo todo a ASCII puro mejora la interoperabilidad. También sacrifica la accesibilidad, la capacidad de búsqueda y la exactitud cultural, porque obliga a escribir mal en español, alemán, japonés y muchos otros idiomas. Decirle a un compañero que escriba mal su propio nombre para que un script funcione no es una política, es una dejación.
Usa mejor un enfoque por capas.
- Conserva el nombre visible en el idioma original. Los nombres de personas y de lugares se quedan bien escritos donde los lee una persona.
- Normaliza a NFC antes de guardar cuando tus herramientas lo permitan, para que todos los sistemas comparen la misma secuencia de bytes.
- Mantén un slug ASCII como identificador para máquinas. Los scripts y las herramientas de sincronización se apoyan en el slug mientras las personas leen el nombre visible.
- Prueba la ruta de transferencia real. Haz viajar archivos de muestra de ida y vuelta por el NAS, la unidad en la nube o el repositorio de Git que tu equipo use de verdad.
Unicode es aceptable. Normalízalo con coherencia, valida la longitud en bytes y comprueba que sobrevive al viaje.
Plantillas por perfil para creativos, desarrolladores, estudiantes e investigadores
Los mismos elementos sirven para cualquier perfil. Lo que cambia es cuál pesa más, porque a cada perfil le duele un tipo distinto de confusión.
| Perfil | Plantilla | Ejemplo | Elemento prioritario |
|---|---|---|---|
| Creativos (diseño, foto, vídeo) | Cliente_AAAA-MM-DD_recurso_vNN.ext | ACME_2026-03-14_banner-portada_v03.psd | Versión y tipo de recurso |
| Desarrolladores | proyecto_componente_tipodoc_vNN.ext | tienda-api_flujo-auth_spec_v02.md | Componente y tipo de documento |
| Estudiantes | Asignatura_trabajo_apellido_vNN_estado.ext | HIST201_ensayo1_garcia_v02_final.pdf | Código de asignatura y estado |
| Investigadores | IDEstudio_AAAA-MM-DD_tipodatos_vNN.ext | ECO07_2026-02-11_encuesta-bruto_v01.csv | ID del estudio y bruto frente a limpio |
Los creativos empiezan por el cliente o el código de proyecto y el tipo de recurso. Una sola campaña puede tener cientos de iteraciones del mismo banner, así que la versión tiene que ser inequívoca y el tipo de recurso tiene que distinguir de un vistazo un banner de portada de un recorte para redes. Sin el elemento de recurso, acabas abriendo archivos para comprobar dimensiones.
Los desarrolladores trabajan dentro de repositorios que ya imponen nombres en minúscula y sin espacios, así que no pelees con el repo. Usa el nombre para el componente y el tipo de documento. tienda-api_flujo-auth_spec_v02.md le dice al revisor exactamente qué parte del sistema describe, algo que importa más que una fecha que el historial de commits ya registra.
Los estudiantes deberían seguir primero lo que indique el profesorado. Si no se especifica nada, el nombre debería llevar el código de la asignatura, el trabajo y el estado de entrega, para que quien corrige un grupo entero encuentre el tuyo en segundos. El apellido ayuda cuando las entregas caen en una misma bandeja compartida.
Los investigadores se juegan más. Nombra de forma distinta los datos brutos y los limpios, marca los brutos como solo lectura y ancla todo a un identificador de estudio y a una fecha. Si los datos limpios sobrescriben a los brutos con el mismo nombre, el estudio no puede reproducirse.
Cómo manejar las excepciones sin romper el sistema
A veces una plataforma impone sus propias reglas. Un portal de entregas puede renombrar las subidas, o una herramienta puede exigir un patrón concreto. Sigue a la plataforma y anota el nombre legible en un README o en un índice del proyecto para que no se pierda la conexión.
Lo mismo vale entre idiomas. El nombre visible puede quedarse en el idioma original mientras el identificador para máquinas sigue en ASCII, y así quedan contentos tanto las personas como las herramientas.
Ponerles nombre a las cosas funciona mejor cuando la estructura de carpetas carga con parte del trabajo, así que combina estas plantillas con una buena estructura de carpetas de proyecto en lugar de forzar todos los datos dentro del nombre del archivo. Si estás metiendo cliente, campaña, región y canal en un mismo nombre, parte de eso pertenece a las carpetas.
Adopta una sola convención y automatiza las comprobaciones
Muchos equipos ni siquiera llegan a hacer el acuerdo. En la encuesta de 2026 de Smallpdf a 1000 profesionales en activo de EE. UU., el 55 % dijo que su equipo no tenía una convención de nombres compartida o estandarizada.
Así que la adopción va antes que la imposición. Publica la guía de una página, consigue el visto bueno de quienes crean los archivos y aplícala a un proyecto activo antes de extenderla a todo. Una convención anunciada por correo a toda la organización suele morir el viernes.
Tres niveles de automatización
El nivel uno revisa los archivos a medida que llegan. Configura reglas de renombrado en las carpetas de entrada, como una acción de carpeta de Automator en macOS o una herramienta que vigile carpetas y marque o corrija las descargas nuevas. Si estás comparando opciones, este repaso de apps de automatización para Mac recoge herramientas que pueden vigilar carpetas y actuar sobre los archivos nuevos.
El nivel dos audita lo que ya hay. Un script corto en Windows o Linux puede listar todos los archivos que rompen el patrón, comprobados contra el mismo orden de elementos de tu guía. Pásalo por la carpeta de un proyecto y verás la deriva de inmediato, incluido quién necesita un repaso.
El nivel tres sigue la tendencia. Haz una auditoría trimestral que cuente los nombres que no cumplen y representa el número a lo largo del tiempo. Una cifra que baja le dice al equipo que el hábito se está formando. Una cifra que sube significa que una regla es demasiado difícil de seguir y hay que revisarla, no imponerla con más voz.
Qué hacer con los archivos que ya tienes
No renombres un archivo histórico a ciegas. Guarda una hoja de correspondencias entre nombres antiguos y nuevos para poder reparar los enlaces de documentos, tickets y correos cuando se rompan. Renombra primero los proyectos activos y deja en paz los archivos cerrados, salvo que alguien siga buscando en ellos.
Haz una cosa esta semana. Elige el próximo proyecto, escribe su plantilla en una página, renombra una carpeta para que coincida y configura una comprobación que se ejecute cada vez que se añada un archivo. Ese pequeño ejemplo funcionando convence a la gente mucho mejor que un comunicado de política.
Una vez que tus nombres sean coherentes, haz que las propias carpetas se distingan mejor. Tintd lee el nombre de una carpeta y elige un icono y un color a juego, y su Folder Watcher da estilo automáticamente a las carpetas nuevas en las ubicaciones que elijas, de modo que un proyecto bien nombrado también se reconoce al instante en el Finder. Visita Tintd para ver cómo la organización visual puede apoyarse en el sistema de nombres que acabas de montar.