I'd say overall it looks pretty well written app code, especially if you say you're a beginner. One thing I'd like to point out is that in my (limited Swift) experience, stuff like this:
https://github.com/NikantVohra/HackerNewsClient-iOS/blob/mas...
...where you're force casting/unboxing/whateveritscalled a bunch of things is a smell. Sometimes it's unavoidable because of the weirdness between Cocoa and Swift, so typically your interface builder outlets will be riddled with that stuff, but for your own internal APIs, try and keep things as option-less as possible.
UI code is pretty challenging to keep organized, especially when platforms encourage using things like two-way bindings and keeping state all over the place. I'd recommend checking out Gary Bernhardt's talk "Boundaries" and Andy Matuschak's similar writings (sorry, can't think of anything off the top of my head), as they have some good ideas for demarcating the line between functional parts of your code that should be super clean and the anything goes world of external UI APIs.
Good luck and keep coding!
Other 2 points I noticed is:
1) You're using CocoaPods but you included SwiftyJSON, Alamofire and a couple of other libraries as plain source code. Why not submodules at least? This makes it hard to update the source of the external dependencies to the latest version
2) You're doing way too many casts in your code. This means that something could be wrong on an architectural level. I would like to help you (I already cloned your repo) but I'm using Swift 1.2 (btw your code is still on Swift 1.1) and I didn't manage to migrate because of point 1).
Apart from that, good job on shipping your app! :)
Good job.
Regarding the code quality - from my experience you'll be able to also see for yourself if the code is well written when you'll want to change something in the app(e.g. in the next update) and see how easy (or not) it is to do so.
Also my advice will be to take a look at other open source projects and try to see how others have done the same things - what was their approach and how is this different from what you would do in a similar scenario.
As the code base grows, doing it this way reliably will become more difficult, to the point that he will begin to fear change.
There is simply no debate that a well tested code base is easier to confidently add features to, confidently refactor and debug than code with no tests at all. This is particularly true if you bring on new contributors who have had no experience with the codebase.
Humans are not computers, they are never as good at repeatedly executing all possible execution paths of an application without growing tired or over confident that it doesn't need to check some path because it's sure it works.
I would take a well tested codebase over a well organized one with no tests any day of the week, because I know I could confidently reorganize the code without breaking anything. (well tested does imply that the tests themselves are well organized, though).
The OP was asking for criticism. He should add tests, lots of 'em.
Was Design+Code your sole source for learning how to program?
I'm not a Swift or iOS developer really, so I don't know how those projects are supposed to be organized, but I glanced through your repo and I can see that you seem to be pretty good at breaking things up into small functions and stuff seems readable and well formatted enough to me. Good luck!
For these reasons, I recommend complementing internet-based code review by measurement: Use (automated) testing in multiple forms, unit, integration, randomised. Count the number of bugs you encounter. Classify the bugs you find, track how the numbers and classes of bugs in your code evolve over time. Compare those statistics with other coders. This not only gives you ideas about your relative coding ability, but will also reveal areas where you could try and improve your abilites.
Anyway, in my experience, the ability to test with ease is one dimenision of design quality.
I like to have a little comment above every function that explains what it does at least. On top of that I usually put a single line above every logical block of code. Something like "Loop trough list of someobject." It seems obvious but it does make it a lot easier to read back code later.
I have to respectfully disagree. This is really, really, REALLY BAD advice.
One should strive to write clean code with short functions, well-named variables and parameters, so that it's easy to understand without redundant comments like "loop trough (sic.) list...". Programming languages have looping constructs (e.g. for-statement). Therefore one does not need to write a comment that describes what a for-statement does.
Also, do not write comments that explain what a function does. Rather, name the function so that it is obvious from the name what it does. If the function does multiple things and name would be too long, split the function into logical subroutines and name them all properly.
It's a little quick-and dirty but it's the way it's commented that makes the point I'm going for here.
# Check if it's something that looks like an ident response
if( input =~ /^(\d+)(|\s),(|\s)(\d+)$/ )
p1 = $1.to_i
p2 = $4.to_i
else
sane = false
end
Rather make a function that does the same and name it for example "ValidateIdentResponse". Write a test for it. Call that function from this function. You get shorter, less-complex main function and you don't need that silly comment.
(EDIT: Formatting)
http://blog.codinghorror.com/code-tells-you-how-comments-tel...