Swift-style-guide: Vorschläge für die nächste Rev

Würden Sie Ihre @IBOutlets aus dem gleichen Grund als privat markieren?

Ich bin da etwas hin- und hergerissen. Einerseits kann @IBActions als öffentlich angesehen werden, da sie einer Schnittstelle ausgesetzt sind. Andererseits gibt es keinen guten Grund, sie offenzulegen, und in Obj-C stecke ich sie immer in die Methodendatei. Eine weitere Überlegung ist, dass Verkaufsstellen und Aktionen, die aus dem IB gezogen werden, immer als intern/öffentlich deklariert werden.

Ich nehme an, wir sollten uns fragen, ob es eine gute Idee ist, eine Abhängigkeit vom @objc -Tag zu erstellen.

Hier sind meine Gedanken:

1) Ich bin gegen die Verwendung des @objc -Tags. Swift entfernt sich aktiv von Objective-C, ebenso wie die RW-Tutorials.

2) Was das Markieren @IBAction und/oder @IBOutlet als allgemeine Regel in Tutorials als private betrifft, so gefällt mir das glaube ich auch nicht.

Ja, bei meinen eigenen Projekten schränke ich den Spielraum so weit wie möglich ein. Ich glaube jedoch nicht, dass dies ein Schlüsselkonzept für _die meisten_ RW-Tutorials ist.

Daher würde ich fragen: "Wird dies von dem Schlüsselkonzept ablenken, das ich in einem Tutorial zu lehren versuche?" Es ist durchaus möglich, dass dies der Fall ist, insbesondere wenn ich erklären muss, warum ich etwas als private markiere, das nicht sofort offensichtlich ist.

Außerdem denke ich, dass dies nur einen weiteren technischen Bearbeitungsschritt zu den _zahlreichen_ Überprüfungen hinzufügen würde, die wir bereits durchführen, und wieder würde ich fragen, wie viel Wert es wirklich in Tutorials bieten wird.

IMHO, ich denke, wir sollten uns auf den Geltungsbereich des Autors und des technischen Redakteurs für @IBAction und @IBOutlet s verlassen, anstatt eine Regel dafür zu haben.

Soweit ich weiß, MÜSSEN Sie das @objc -Tag verwenden, um die Auswahlfunktion als privat markieren zu können.

Ja, ich markiere meine @IBOutlets definitiv als privat. Sie sind ein Implementierungsdetail, das externen Aufrufern nicht offengelegt werden sollte, es sei denn, dies ist absolut notwendig.

Bitte denken Sie daran, dass der Styleguide kein Tutorial-Leitfaden ist. Wenn das die Absicht ist, dann hören Sie auf, dafür zu werben, und machen Sie es nur für die Autoren intern. Sie haben Tonnen von Leuten aus dem ganzen Web, die das als ihren Styleguide verwenden. Es sollte gutes Benehmen fördern, nicht nur das, was für ein Tutorial praktisch ist.

Es stört mich immer, wenn ein Tutorial Dinge überspringt, nur um es einfach zu machen, da wir Leute haben, die neu in der Entwicklung sind, die von Ihren Tutorials LERNEN, und Sie ihnen also beigebracht haben, Dinge suboptimal zu machen.

Danke für das Feedback und die Anregungen.

@objc -Methoden müssen nicht vollständig dynamisch versendet werden, um als privat markiert zu werden. Zutrittskontrolle und Versand stehen in keinem Zusammenhang. Zum Beispiel die folgenden Arbeiten:

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

Ich vermute, dass Sie etwas anderes im Sinn hatten, und ich würde es gerne verstehen.

PS:
In Bezug auf den Zweck des Leitfadens glaube ich, dass er im ersten Absatz ziemlich klar angegeben ist. Persönlich verwende ich eine gegabelte Version davon in meinen eigenen Projekten mit Änderungen an der Abstandsregel, dem Copyright-Header und einigen zusätzlichen UIKit- und IB-Regeln. Ich denke, es kann oft als Ausgangspunkt verwendet werden.

Das Problem, auf das sich @grosch bezieht, ist die Verwendung von Selektoren.
let recognizer = UITapGestureRecognizer(target: self, action: #selector(buttonTapped(_:)))

Damit der Selektor privat ist, muss er entweder:
<strong i="10">@objc</strong> private func buttonTapped(sender: UITapGestureRecognizer)
oder
private dynamic func buttonTapped(sender: UITapGestureRecognizer)

Ah, jetzt verstehe ich. Danke! 👋
Mit private markierte Methoden aus einer Obj-C-kompatiblen Klasse werden nicht dynamisch versendet (dh sind keine Selektoren). In gewisser Weise deckt der aktuelle Leitfaden dies eigentlich bereits ab. Privates sollte generell als privat gekennzeichnet werden, um die Übersichtlichkeit zu verbessern. Siehe https://github.com/raywenderlich/swift-style-guide#access-control
Sobald es mit private markiert ist, ist es vollständig ein Implementierungsdetail der Klasse. Wenn Sie es irgendwo als Selektor bezeichnen müssen, haben Sie keine andere Wahl, als es zu einem zu machen. Ich denke, es ist besser, bei diesem zweiten Teil faul zu sein, denn mit Swift 3 ... (oops, ich meine Swift 4) ABI-Resilienz, das Ändern einer privaten Methode wird keine bahnbrechende Änderung sein. Indem Sie private Methoden mit @objc markieren, verhindern Sie außerdem aktiv, dass der Optimierer Inlining usw. durchführt, sodass dies einen erheblichen Nachteil hat.