Coding style for internal/private variables

Using Swift
1

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

2

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@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

3

From what I've observed, preceding (rather than trailing) single underscores indicate private use. The standard library includes a fair number of "Apple Internal" (I guess now "Swift Team Internal") variables, methods, functions, etc that follow this practice. This practice is, as far as I can tell, uncoupled with access levels. A function named _foo(), while global and public, is still "hands off please".

All in all, other "Hungarian Style" conventions, that is modifying the name to indicate types and uses, are not used in Swift or among most Swift developers.

-- E

···

On Jun 1, 2016, at 10:02 AM, Adrian Zubarev via swift-users <swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

4

I never liked the underscores (so for me, they have been the best choice to mark stuff I should not know of in Cocoa ;-).
For several years, I prefixed instance variables with "m", but stopped doing so after a talk about bad habits in writing Java code:
It is like Hungarian notation, which also puts redundant information into names — and if even Java-folks think it's anachronistic… ;-)

Objective-C lacked some features that Swift has, so workarounds had been created; but those shouldn't be carried over (by the way: It's similar with file names and those extensions, and a modern file system for OS X is years overdue ;-)

5

@Austin: do you use self._name or just _name in your code?

I’ve seen self._name usage in swifts standard libraries and didn’t liked it at first glance, but it feels alright now.

My personal habit is to write self. everywhere it’s possible, because as soon as some private variable is nested inside a closure I’ll be forced to write self._name which does look odd if every other _name usage doesn’t contain self.. Again that’s my personal view.

···

--
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 18:52:27, Erica Sadun (erica@ericasadun.com) schrieb:

From what I've observed, preceding (rather than trailing) single underscores indicate private use. The standard library includes a fair number of "Apple Internal" (I guess now "Swift Team Internal") variables, methods, functions, etc that follow this practice. This practice is, as far as I can tell, uncoupled with access levels. A function named _foo(), while global and public, is still "hands off please".

All in all, other "Hungarian Style" conventions, that is modifying the name to indicate types and uses, are not used in Swift or among most Swift developers.

-- E

On Jun 1, 2016, at 10:02 AM, Adrian Zubarev via swift-users <swift-users@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

6

I think the IDE should colorize differently these variable names.

···

On 01 Jun 2016, at 18:02, Adrian Zubarev via swift-users <swift-users@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

7

A little bit off-topic: Is there any way to create autocompletion shortcuts in Xcode that will show only private, internal or both values of an instance?

class Foo {
    private var integer: Int = 0
    internal var string: String = "foo"
    internal func boo() {}
}

let instance = Foo()

instance.@p

···

________________
        >[V] Int integer |
        >________________|
                 
// where @p is an autocompletion shortcut for Xcode that will filter private vars, functions etc.
// when you choose one `@p` will be replaced

// or @i for internal
instance.@i
         __________________
        >[M] Void boo() |
        >[V] String string |
        >__________________|
Something like this would be handy.

--
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 18:23:46, Tino Heth (2th@gmx.de) schrieb:

I never liked the underscores (so for me, they have been the best choice to mark stuff I should not know of in Cocoa ;-).
For several years, I prefixed instance variables with "m", but stopped doing so after a talk about bad habits in writing Java code:
It is like Hungarian notation, which also puts redundant information into names — and if even Java-folks think it's anachronistic… ;-)

Objective-C lacked some features that Swift has, so workarounds had been created; but those shouldn't be carried over (by the way: It's similar with file names and those extensions, and a modern file system for OS X is years overdue ;-)