Alright, so here are five tips that can make your Swift code look more professional.

Tip#1

Follow Apple’s naming conventions.

If you have worked with other programming languages, it might be tempting to use the naming and coding style you’re used to. However, Swift has its own naming rules, so do your best to apply them. As the saying goes: “When in Rome, do as the Romans do.”

Apple provides more details and examples in their API design guidelines. The bottom line is this: name your protocols, functions, types, properties, methods, variables, parameters so that their purpose is clear. Clarity is more important than brevity.

Tip#2

Don’t use semicolons! 

Swift doesn’t require semicolons at the end of code lines. You can still use them if you wish – your code will compile just fine. However, semicolons add to the cognitive load without improving the readability of your code. 

The Swift community dropped the semicolons – you can check any popular open-source Swift library – so it’s not a bad idea to follow them.

In short: don’t use semicolons at the end of your Swift code lines. 

Tip#3

Use access control.

Swift provides five different access levels: public/open, internal, file-private and private. If you don’t specify an access level for your entities, the default applies, which is internal. Internal access means that the given entity can be used from any source file in your project. This may not be what you want. Should that helper method be accessible from all parts of your project? How about all those properties? Do you really want to expose them? Ask yourself if something should be used outside of its defining type or source file.

Tip#4

Exit early.

You should deal with the error case up front and exit the current scope as soon as possible. The guard statement lets us concisely implement the early exit strategy. The purpose of the guard statement is clear, and it’s way cleaner than using if-else conditional logic. 

Tip#5

Structure your code.

You’ve probably heard about the infamous Massive View Controller syndrome. It starts with a skinny, auto-generated view controller – UIViewController, UITableViewcontroller, you name it. You start implementing new features. You’ll add some delegates; then you’ll need some helper methods, calculated properties, protocol conformance, and so on. 

Your view controller grows as you keep adding new features. Eventually, the code becomes a huge mess, with dozens of methods, properties, delegates and what not.

Swift type extensions provide an elegant way to structure your code. Instead of packing everything in a big, monolithic class, you create extensions. You can even extract the extension into a separate Swift source file.