== false
while found == false
We'd prefer to see either this:
while !found
or this:
while notFound
(where in the second example, we reverse the boolean logic you've used)
Vertical White Space
A blank line between every line of code is not productive. It adds wear to my scroll wheel and makes your code harder to digest.
Instead, we should think of blank lines as a way of taking a breather. They should separate logical chunks of code within a function or method.
Single Responsibility
I'd guess that this is all simply dumped into a playground, which is fine. But we can still write functions in the playground. And we should.
We've got quite a lot of nesting. Any time we have nesting is an indicator that we should be refactoring into functions.
Most importantly, functions have names. Using functions allows us to write more readable code without using comments because we're breaking our code up into small logic chunks that make sense together and giving each of these chunks a name (the function name).
Also, breaking our code into these chunks makes sure we don't choke on the elephant.
;
Semicolons are optional in Swift.
Before anything else, we should be consistent. Using semicolons on two lines and omitting on other lines has the potential to be confusing. If you want to use semicolons, you need to use them everywhere.
But this is Swift, and in Swift, we prefer omitting semicolons. I don't use semicolons anywhere in Swift.
Traditional for Loops.
We should basically never use these in Swift. I can't think of any scenario which requires their usage. First of all, from a style and readability standpoint, this is actually harder to read than the Swift alternatives, which make more sense from a plain-English point of view. The only reason the traditional for loops are even remotely readable is because of the decades of history that the C language has dumped on us.
We should vastly prefer something more like this:
for iterator in 2...20 {
// do something with 2 through 20 inclusive...
}
And beyond the style comment, these Swift loops are actually faster than the traditional for loops. (And this explains how I manage to never use semicolons in Swift.)
var versus let
var declares a variable. let declares a constant.
We should always prefer let to var. The only time we should use var is when we're confident we will need to modify the value. Very few of your values need to be modified and most can be declared as let values.
Magic Numbers
Your code is littered with magic numbers. Rather than magic numbers, we should declare constants and name all of these numbers. Although, if we properly broke our code up into functions, most of these magic numbers would go away in place of function input arguments.
The only magic number in here we can't really get rid of is 0. Any time a number's best variable name would simply be the name of that number, it's not really a magic number. The only number for which this actually applies in your code is 0.
However, with that said, we can take care of zero with a function in this case:
extension Int {
func isMultipleOf(divisor: Int) -> Bool {
return self % divisor == 0
}
}
We still have 0 in here, but it's wrapped inside a very small, very concise, very aptly named function that describes exactly what's going on here.
In summary...
Of course, this answer hasn't addressed any performance concerns. I've only addressed style concerns. I think style is one of the most important things to get right very early, before you've dug yourself into lots of bad habits.
For examples on what this might look like both in terms of better style and better performance, you can check out my question regarding this very same Project Euler challenge.
I'll be glad to help you with performance issues, but others have already addressed this, and I wouldn't really be able to say anything besides "go look how I did it, plus the performance-related answers I got". I wanted to emphasize Swift-style however, because I'm not sure how likely it is that any performance-related comments will be applicable to the next Swift code you write, but all of these style-related comments will absolutely be applicable.
And the better your style it is, the easier it is for both yourself and any reviewer to look at and focus on performance issues.
