Replies: 1 comment 1 reply
-
Hi @jeffremer, Thank you for your suggestion, we are indeed aware of this. But unfortunately, this decision was made a while ago by the previous iOS Team. For now, we will need to live with this since changing this right now would cause a lot of breaking changes, or deprecated flags everywhere. At the moment, we have much more high-priority things to deal with. But we will keep this in mind for sure for future major releases. Best, |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'll admit right up front that this discussion is going to sound very nit-picky, but hopefully it can be productive. Otherwise tell me to shut up and I will accept things the way they are and move on. Please treat this as a friendly suggestion, with the willingness to understand if things are the way they are for a very good reason.
I've noticed that the StreamChat Swift SDK uses non-standard abbreviations for view controller names, such as
ChatMessageReactionsPickerVC
-ViewController
is abbreviatedVC
.For what it's worth, Apple recommends that you do not abbreviate the names of things, even if they are common, even if they are long - aside from well known acceptable abbreviations. You may use commonly use
VC
as an abbreviation, as may some others, but it does not follow platform conventions and it sacrifices clarity for the sake of brevity. It is an unpredictable and potentially overlapping abbreviation. For instance, abbreviating something with aVC
suffix,TVC
, andCVC
for view controller, table view cell or collection view cell respectively creates an unclear overlapping set of abbreviations.Xcode does a fairly good job of handling searching for something with any of those suffixes with the quick open feature, but Xcode's quick open is far from the only method of navigating code or symbol names. Trying to enumerate symbols within a binary to get a quick idea of how many view controllers there are, programmatically for instance, becomes far more difficult when things are not named consistently.
Again…sure this might sound like nit-picking, and granted it is not a high urgency problem, but at the very least this is the kind of code smell that we shouldn't expect from a public SDK. Including non-standard abbreviations like this in a public SDK hints at the acceptability of doing so. Adopters may then also inconsistently and unpredictably spread similar practices. Consistent naming conventions exist in order to make our lives easier, clarity is more important than brevity.
Beta Was this translation helpful? Give feedback.
All reactions