[swift-users] Coding style for internal/private variables

Austin Zheng austinzheng at gmail.com
Wed Jun 1 11:44:53 CDT 2016


I've actually used the _underscore convention in Swift to denote "private" members that nobody outside the type should touch, but that I want to expose to an extension on that type defined in a different file. It's a convention that works decently well with a little discipline.

Some time back, I pitched a few ideas for defining an access level that would allow you to limit access to a type to the type itself and any extensions on that type in the same project, but they went nowhere. Probably for the better, given the amount of complexity they would have introduced.

Austin

> On Jun 1, 2016, at 9:02 AM, Adrian Zubarev via swift-users <swift-users at swift.org> wrote:
> 
> I’d like to talk about your personal coding styles in swift for its access control.
> 
> Remember these variable names like __magic or _spell or even garbage_?
> 
> Sure swift solves the synthesize problem but there might be old habits that let us write such code.
> 
> Here are some examples:
> 
> internal _name
> internal i_name
> private __name
> private p_name
> 
> // not sure where `garbage_` would fit
> I’d love to see your responses and opinions what and why the style you choose suits you.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org <mailto:swift-users at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160601/f7f1a2e1/attachment.html>


More information about the swift-users mailing list