self. becomes noise” argument I really can’t follow. I use
self. as a search term in Xcode and I explicitly look for
self. in code reviews.
What can't you follow about the argument? Could you be more specific?
You mention your rigorous and diligent approach to
self., right after, but I fail to understand how does that factor into the argument. It's just that if most people reasoned about code as you do, and most projects had the same challenges as SwiftNIO, this simply wouldn't be a problem, right?
Not trying to be cheeky here. I really want to understand where you're coming from, and I'm sure you're not alone in this either.
Today my strategy often is to make a given part of a method temporarily a
static func which requires me to list all the “inputs” explicitly as function parameters, all that just to be sure nothing uses
self. without me noticing...
Is it possible that you might be focusing too much on SwiftNIO as your primary case study? I don't know much about that project, but at least I can infer a few things:
- The average level of an app dev is probably lower than that of a SwiftNIO developer.
- Ensuring sound architectural integrity is probably more important to SwiftNIO than the majority of iOS apps.
- That will probably translate in a more rigorous development policy than the average iOS app.
- From what you describe, the challenges around state and memory management seem to be significantly harder than the average iOS app.
- I'd venture to say SwiftNIO is an unusual Swift project to the point it may very well be unique.