I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style. Oh, and they say that like it's a bad thing
Depending on what they mean by this, I agree that it can be a bad thing.
Years ago, in the days when Swift was still pretty green (around 2.x or 3.x) I knew someone who liked to try to write "Objective-C in Swift" — that is, they'd try to ignore the type system and optionality entirely, with lots of forced casts, forced unwraps, shipping data around in [String:Any] dictionaries, etc… constant fighting with the compiler that made SourceKit very unhappy and crashy and the app we were working on more crash-prone than it would've been had it been written in Objective-C.
On the other hand, if it's just a more verbose style that favors clarity and avoids e.g. unnamed closure arguments and breaks more out into well named variables and functions, I don't see anything wrong with that at all and in fact have been leaning further in that direction as time goes on.
Ha ha, yeah no I would never force a cast, I always unwrap optionals...
As an example, I was slow to adopt guard statements generally, preferring to strictly use them only for parameter checking (thus only at the top of functions).
Then there are crazy ways that case statements can be used in a switch that I still don't understand.
Comments
I know what you mean regarding Swift.
In recent decades different languages have introduced interesting patterns, interesting notations. Swift seems to have adopted about all of them.
I have been told by teammates that I don't write "Swifty" Swift code, instead writing something more like an "Objective-Swift" style.
Oh, and they say that like it's a bad thing.
Depending on what they mean by this, I agree that it can be a bad thing.
Years ago, in the days when Swift was still pretty green (around 2.x or 3.x) I knew someone who liked to try to write "Objective-C in Swift" — that is, they'd try to ignore the type system and optionality entirely, with lots of forced casts, forced unwraps, shipping data around in [String:Any] dictionaries, etc… constant fighting with the compiler that made SourceKit very unhappy and crashy and the app we were working on more crash-prone than it would've been had it been written in Objective-C.
On the other hand, if it's just a more verbose style that favors clarity and avoids e.g. unnamed closure arguments and breaks more out into well named variables and functions, I don't see anything wrong with that at all and in fact have been leaning further in that direction as time goes on.
Ha ha, yeah no I would never force a cast, I always unwrap optionals...
As an example, I was slow to adopt guard statements generally, preferring to strictly use them only for parameter checking (thus only at the top of functions).
Then there are crazy ways that case statements can be used in a switch that I still don't understand.