Dear Erica: Snake Case

An anonymous reader writes, “Is there is ever a good reason to use snake case in Swift code?”

Although I’m tempted to respond with a snarky no_there_isn't, of course you’ll use snake case, and with good reason. The real world offers many legacy and non-native libraries. Coders often source snake case calls and constants in their production code.

When developing your own symbols, the Swift community consensus has centered on UpperCamel for type and protocol names and lowerCamel for members, freestanding functions, and other symbols. This is a non-binding convention but it will make your code look and feel more Swifty.

4 Comments

  • I find it more readable to name tests in snake case, since they are often whole sentences.

    testUserTokenSavedAfterUserLogsInSuccessfully
    test_user_token_saved_after_user_logs_in_successfully

    For long method names with lots of different word lenghts, snake case feels more readable.

  • Write in whatever your paymaster wants. If it’s RPN and pull_my_finger, then freakin’ do it…

  • I wonder why is it called snake case? Seems overusing jargon to obscure something simple to express in plain English, using “lowercase with underscores for spaces” or “low_underscore”.

    • “snake case” sounds rather better than “lowercase with underscores for spaces”…