Un expediente compartido acumula archivos con nombres parecidos. «Final», «final2», «envio» y «ok» conviven durante días hasta que alguien abre el incorrecto. El problema no es estético. Un nombre ambiguo convierte una carpeta en un sorteo: cada persona cree saber cuál es la versión vigente y ninguna puede demostrarlo sin abrir el fichero.
El nombre no sustituye un sistema de control de versiones. Tampoco demuestra que el contenido sea el acordado. Su función es más modesta y más urgente: reducir la probabilidad de que dos personas trabajen sobre objetos distintos creyendo que hablan del mismo documento.
El punto de partida es distinto de elegir un nombre para el fichero: aquí el asunto ya tiene nombre. Falta acordar quién asigna las revisiones y qué ocurre cuando dos colaboradores guardan cambios simultáneos. Una regla útil puede reservar la numeración a quien prepara la entrega, mantener las propuestas separadas hasta revisarlas y anotar qué propuesta se incorporó. Así se evita que el número mayor gane por accidente sin una decisión compartida.
Lo que el nombre tiene que distinguir
Un nombre útil responde, al menos, a tres preguntas. De qué asunto se trata, de qué objeto dentro de ese asunto y de qué estado se trata. El asunto evita mezclar contratos de clientes distintos. El objeto evita mezclar un presupuesto con un anexo. El estado evita mezclar un borrador interno con una copia ya enviada.
La fecha ayuda cuando se escribe de forma inequívoca. El perfil de fechas de W3C y RFC 3339 describen representaciones de fecha y hora con año, mes y día en orden fijo, precisamente para que «03/04» no dependa del país de quien lee. [1][2] Un equipo no necesita adoptar ese formato al detalle. Sí necesita que dos personas no interpreten la misma cifra de dos maneras.
El identificador de versión puede ser un número correlativo, una fecha de preparación o una etiqueta de estado —recibido, trabajo, enviado— siempre que el equipo use el mismo criterio. Mezclar «v3» de una persona con «rev-b» de otra recrea la ambigüedad que se quería evitar.
Lo que el nombre no puede cargar
Un nombre de fichero es un identificador corto, no un acta. Si se intenta resumir todo el historial —quién cambió qué cláusula, por qué se recortó una página, a quién se envió— el nombre se vuelve ilegible y se deja de usar. Lo que no cabe en el nombre debe vivir en una nota del expediente o en el registro de cambios.
Tampoco conviene cifrar el contenido en abreviaturas privadas. Una sigla que solo entiende quien la inventó falla en cuanto otra persona entra en la carpeta. El nombre debe poder leerse fuera de la conversación del día. Si hace falta un código interno, ese código tiene que estar documentado en el mismo expediente, no en un chat que caduca.
Los términos de Dublin Core recogen propiedades como título, identificador y fecha como descripciones del recurso, no como un único campo milagroso. [3] Separar el nombre visible de otras notas es coherente con esa idea: el fichero se encuentra por el nombre; se comprende por el conjunto de datos que lo rodean.
Convenciones que sobreviven a más de una persona
Una convención funciona cuando se puede aplicar sin preguntar. El orden de los elementos, el separador y el significado de cada etiqueta deben ser estables. Si «envio» a veces significa «ya salió» y a veces «listo para salir», el nombre deja de informar.
En carpetas compartidas, el conflicto de nombres es habitual: dos personas guardan el mismo identificador. Sobrescribir no avisa a quien tenía abierta la copia anterior. Añadir iniciales o un número de secuencia local sin regla produce otra vez duplicados. Mejor acordar quién numera y dónde se deja la versión vigente.
El nombre también debe ser portable. Caracteres reservados, acentos mal interpretados por un visor o rutas demasiado largas pueden impedir abrir el archivo en otro equipo. Una convención austera —letras, números, guiones y una fecha— suele viajar mejor que un título literario. Eso no mejora el contenido; solo reduce un fallo de acceso.
La convención necesita resolver también los conflictos: si dos personas reservan el mismo número, alguien debe decidir cuál continúa la secuencia y dejar la otra propuesta identificada como alternativa. El nombre señala una versión; la decisión sobre cuál sigue vigente pertenece al registro del equipo. No conviene confundir ambas funciones.
Cómo tratar «final» y «última»
«Final» es el nombre más frágil porque invita a reutilizarlo. Cada corrección posterior o bien lo sobrescribe o bien genera «final-definitivo». En un expediente vivo, casi nunca hay un final absoluto: hay una versión enviada en una fecha a un destinatario. Nombrar esa entrega por fecha y destinatario, o por un número de envío, deja sitio para la siguiente sin borrar la anterior.
«Última» falla por la misma razón. Última según quién y en qué carpeta. En un directorio sincronizado, la copia más reciente por fecha de modificación puede ser un recorte accidental, no la versión de trabajo. La fecha del sistema de archivos no equivale a la fecha editorial del documento.
Cuando se recibe un archivo externo con un nombre propio, conviene no renombrarlo a ciegas si ese nombre es la única referencia que la otra parte reconoce. Se puede añadir un identificador interno sin destruir el nombre recibido, o conservar el recibido junto a la copia de trabajo. Perder el nombre original complica cualquier reclamación del tipo «os enviamos este fichero».
Una regla corta para el equipo
Antes de guardar, preguntar si otra persona, sin el chat del día, sabría qué abrir. Si la respuesta depende de «el que está en verde» o «el de esta mañana», el nombre no basta. Completar asunto, objeto y estado. No reutilizar «final». No guardar encima de la referencia recibida.
Si el equipo cambia de criterio, hay que documentar el cambio y no reescribir en silencio los nombres antiguos. Un histórico con dos convenciones es legible si se sabe cuándo cambió la regla. Un histórico reetiquetado a medias parece ordenado y está roto.
El nombre de versión no demuestra calidad ni autenticidad. Evita una clase concreta de error: entregar o editar el archivo equivocado porque todos se llamaban casi igual.
Fuentes
- W3C. Date and Time Formats. https://www.w3.org/TR/NOTE-datetime
- IETF. RFC 3339. Date and Time on the Internet: Timestamps. https://datatracker.ietf.org/doc/html/rfc3339
- Dublin Core Metadata Initiative. DCMI Metadata Terms. https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
