Swift-style-guide: Sugerencias para la próxima revisión

¿Marcarías tu @IBOutlets privado por la misma razón?

Estoy un poco desgarrado en este. Por un lado, @IBActions pueden verse como públicos ya que están expuestos a una interfaz. Por otro lado, no hay una buena razón para exponerlos y en Obj-C, siempre los coloco en el archivo de método. Otra consideración es que las salidas y acciones arrastradas desde el IB siempre se declaran internas/públicas.

Sin embargo, supongo que deberíamos preguntarnos si es una buena idea crear una dependencia en la etiqueta @objc .

Aquí están mis pensamientos:

1) Estoy en contra de usar la etiqueta @objc . Swift se está alejando activamente de Objective-C, al igual que los tutoriales de RW.

2) Respecto a marcar @IBAction y/o @IBOutlet como private como regla general en los tutoriales, tampoco creo que me guste.

En mis propios proyectos, sí, limito el alcance tanto como sea posible. Sin embargo, no creo que este sea un concepto clave para la mayoría de los tutoriales de RW.

Por lo tanto, me preguntaría: "¿Esto restará valor al concepto clave que estoy tratando de enseñar en un tutorial?" Es muy posible que así sea, especialmente si tengo que explicar por qué estoy marcando algo como private que no es inmediatamente obvio.

Además, creo que esto agregaría solo otro paso de edición técnica a las _numerosas_ verificaciones que ya estamos haciendo y, nuevamente, me preguntaría cuánto valor realmente proporcionará en los tutoriales.

En mi humilde opinión, creo que deberíamos deferir al autor y al editor técnico el alcance de @IBAction y @IBOutlet s en lugar de tener una regla al respecto.

Hasta donde yo sé, TIENE que usar la etiqueta @objc para poder marcar la función del selector como privada.

Sí, definitivamente marco mi @IBOutlets como privado. Son un detalle de implementación que no debe exponerse a llamadas externas a menos que sea absolutamente necesario.

Recuerde que la guía de estilo no es una guía de tutorial. Si esa es la intención, deja de publicitarlo y hazlo interno solo para los escritores. Hay toneladas de personas de toda la web que usan eso como su guía de estilo. Debe fomentar el buen comportamiento, no solo lo conveniente para un tutorial.

Siempre me molesta cuando un tutorial omite cosas solo para hacerlo más fácil, ya que tenemos personas nuevas en el desarrollo que APRENDEN de sus tutoriales, y les ha enseñado a hacer las cosas de manera subóptima.

Gracias por los comentarios y sugerencias.

Los métodos @objc no necesitan tener un envío dinámico completo para que se marquen como privados. El control de acceso y el despacho no están relacionados. Por ejemplo, los siguientes trabajos:

    <strong i="8">@IBAction</strong> private func buttonTapped(sender: UIButton) {
    }

Supongo que tenías algo más en mente, y me gustaría entenderlo.

PD:
Con respecto al propósito de la guía, creo que quedó bastante claro en el primer párrafo. Personalmente, uso una versión bifurcada en mis propios proyectos con modificaciones en la regla de espaciado, el encabezado de derechos de autor y algunas reglas adicionales de UIKit e IB. Creo que a menudo se puede utilizar como punto de partida.

El problema al que se refiere @grosch es el uso de selectores.
let recognizer = UITapGestureRecognizer(target: self, action: #selector(buttonTapped(_:)))

Para que el selector sea privado, debe ser:
<strong i="10">@objc</strong> private func buttonTapped(sender: UITapGestureRecognizer)
o
private dynamic func buttonTapped(sender: UITapGestureRecognizer)

Ah, ya veo. ¡Gracias! 👋
Los métodos marcados private de una clase compatible con Obj-C no se distribuyen dinámicamente (es decir, no son selectores). En cierto modo, la guía actual ya cubre esto. Las cosas privadas generalmente deben marcarse como privadas para mejorar la claridad. Consulte https://github.com/raywenderlich/swift-style-guide#access-control
Una vez marcado private , es totalmente un detalle de implementación de la clase. Si necesita referirse a él como un selector en algún lugar, realmente no tiene otra opción que convertirlo en uno. Creo que es mejor ser perezoso con esta segunda parte porque con Swift 3... (ups, me refiero a Swift 4) resiliencia ABI, cambiar un método privado no será un cambio importante. Además, al marcar métodos privados con @objc , está evitando activamente que el optimizador se inserte, etc., por lo que existe una desventaja significativa al hacerlo.