Nombrar bien: etiquetas, verbos y el par que muta

Swift es uno de los poquísimos lenguajes cuyo diseño de nombres se apoya explícitamente en categorías gramaticales del inglés: verbos, participios, gerundios, sintagmas preposicionales. Para quien viene de otra tradición esto suena a pedantería, pero cumple una función técnica muy concreta. La gramática es el único sistema de expectativas compartido que existe antes de que tu API exista, y apoyarse en ella permite que un lector deduzca el comportamiento de un método —si muta, si devuelve, si es caro, si tiene efectos— sin haber visto jamás su declaración. Las etiquetas de argumento son la pieza que hace posible ese truco, y también la que más se malinterpreta.

La etiqueta pertenece a la frase, no al parámetro

El error de origen consiste en pensar que la etiqueta externa es el nombre del argumento. No lo es: el nombre del argumento es el identificador interno, el que usa el cuerpo de la función. La etiqueta externa es un fragmento de la frase que se leerá en la llamada, y por eso su criterio de calidad no es describir el parámetro, sino encajar gramaticalmente con el nombre del método.

// La etiqueta describe el parametro: rigido y redundante
func mover(distancia: Double, direccion: Direccion)
mover(distancia: 3, direccion: .norte)

// La etiqueta completa la frase: fluido y mas informativo
func mover(_ distancia: Double, hacia direccion: Direccion)
mover(3, hacia: .norte)

De aquí salen dos patrones canónicos. Cuando el método admite una preposición natural, la preposición es la etiqueta y arrastra a todos los argumentos que gobierna: mover(desde: a, hasta: b) mantiene la preposición pegada a la etiqueta porque rige ambos. Cuando el primer argumento forma parte de una frase verbal completa, la etiqueta se suprime y el resto lleva las suyas: vista.añadir(hijo, debajo de: otra).

Hay un caso frontera que conviene tener resuelto de antemano. Si los argumentos son intercambiables entre sí y ninguno domina —los elementos de una suma, los vértices de un triángulo— no hay frase que construir y todas las etiquetas deben suprimirse o ser idénticas, porque inventar etiquetas distintas sugiere una asimetría que no existe.

Verbos que actúan, sustantivos que devuelven

La segunda regla es la que más comportamiento comunica por unidad de esfuerzo, y se enuncia en una línea: si la operación tiene efecto sobre el receptor, nómbrala con un verbo en imperativo; si devuelve un valor nuevo sin tocar nada, nómbrala con un sintagma nominal.

var lista = [3, 1, 2]

lista.ordenar()                 // verbo: actua sobre lista
let otra = lista.ordenada()     // sustantivo: devuelve una copia

conexion.cerrar()               // verbo: efecto sobre la conexion
let estado = conexion.estado    // sustantivo: solo consulta

La regla se apoya en una intuición lingüística sólida: un imperativo pide una acción y por tanto anuncia consecuencias; un sintagma nominal designa una cosa y por tanto anuncia un resultado. Cuando un método viola la correspondencia —un nombre nominal que además muta, un verbo que solo consulta— el lector construye un modelo mental equivocado y el compilador no puede ayudarle, porque el sistema de tipos no distingue entre efecto pretendido y efecto real.

Los booleanos merecen su propia cláusula. Una propiedad o método que devuelve Bool debe leerse como una aserción sobre el receptor, lo que en la práctica significa empezar por is, has, can o un adjetivo. Y los protocolos siguen otra regla complementaria: los que describen qué es algo se nombran con sustantivos, y los que describen qué puede hacer algo con sufijos de capacidad como able o ible.

flowchart TD
A[Que hace la operacion] --> B{Modifica el receptor}
B -- Si --> C[Verbo en imperativo]
B -- No --> D{Devuelve un booleano}
D -- Si --> E[Asercion con is o has]
D -- No --> F[Sintagma nominal]
C --> G[Existe tambien version no mutante]
G -- Si --> H[Sufijo ed o ing en la copia]
style C fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b
style H fill:#89b4fa,color:#11111b

El par mutante y no mutante

Cuando una misma operación tiene sentido en ambas formas, Swift no te deja elegir nombres arbitrarios: exige un par derivado del verbo, y la regla que gobierna la derivación es gramatical, no ortográfica.

Si el verbo admite participio pasado con sentido de resultado, la versión no mutante lo usa: ordenar y ordenada, invertir e invertida. Si el participio no funciona porque el verbo es en realidad un sustantivo verbalizado —el caso de union, difference, intersection— entonces la versión mutante toma la forma de gerundio o de verbo explícito y la no mutante conserva el sustantivo. En inglés esto produce el par conocido formUnion y union, cuya asimetría desconcierta hasta que se entiende que el sustantivo ya nombraba al resultado y no había participio disponible.

protocol Transformable {
    mutating func normalizar()            // efecto
    func normalizada() -> Self            // resultado
}

extension Transformable {
    func normalizada() -> Self {
        var copia = self
        copia.normalizar()
        return copia
    }
}

Ese patrón tiene una consecuencia de diseño que va más allá del nombre. Al declarar el par en un protocolo y proveer la versión no mutante en una extensión por defecto, obligas a cada conformante a implementar solo la variante mutante, que es la que puede optimizarse in situ, y regalas la otra con coste de una copia. La alternativa simétrica —implementar la no mutante y derivar la mutante por asignación— es correcta pero pierde la oportunidad de mutar sin copiar, y en tipos con almacenamiento grande esa diferencia es medible.

En castellano el par cae con naturalidad porque disponemos de participios con género —ordenar y ordenada, filtrar y filtrada— pero conviene no perder de vista que el par publicado en una biblioteca real se escribirá en inglés, y que ahí la elección entre participio y gerundio no es libre: la decide si el nombre base es verbo o sustantivo, y equivocarse produce nombres que suenan mal a cualquier lector nativo.

Conviene además recordar que la palabra clave mutating solo existe en tipos de valor. En una clase todo método puede modificar el estado sin anunciarlo, lo que significa que en clases el par de nombres ya no lo respalda el compilador y depende enteramente de tu disciplina. Es una razón más, y no menor, para preferir tipos de valor en el diseño de bibliotecas.

Cuando suprimir la etiqueta y cuándo no

El guion bajo es la herramienta más peligrosa del repertorio porque parece un simple ahorro y en realidad borra información en el punto de uso. Las guías admiten su uso en tres situaciones y desaconsejan el resto.

La primera es la de los argumentos que no se distinguen entre sí, ya comentada. La segunda es la de las funciones que forman parte de un dominio con notación establecida, donde la etiqueta rompería la convención: nadie escribe una raíz cuadrada con etiqueta. La tercera, y la más frecuente, es la del argumento que ya está nombrado por el propio método, como el elemento en añadir o el valor en insertar.

// Correcto: el metodo ya dice que se anade un elemento
lista.añadir(elemento)

// Peligroso: dos enteros sin etiqueta y sin simetria
func recortar(_ inicio: Int, _ fin: Int)
recortar(3, 9)     // cual es cual, y estan incluidos

// Reparado
func recortar(desde inicio: Int, hasta fin: Int)

El criterio final vuelve a ser el de la lección anterior: la etiqueta se suprime cuando su presencia no elimina ninguna pregunta, y se conserva cuando su ausencia crea una. Toda supresión que obligue al lector a recordar el orden de los parámetros es una supresión mal hecha, por muy elegante que quede la llamada.