21–30 of 44 posts
Have they fixed testing with Swift yet? I am normally a pretty test driven person, but honestly, Apple makes it pretty annoying to use tests with Swift, so I don't blame you for your lonely scaffold. 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/Ha…
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.
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! :)
In my experience it's useful to add a little more documentation/comments to your code. It makes it a lot more readable for anyone else and more importantly, a lot easier for yourself when you're writing updates a while from now. 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 tr…
It's a little quick-and dirty but it's the way it's commented that makes the point I'm going for here.
After several years in a test-driven development team, seeing your test directory made me cringe :/
Yeah I know I need follow the best practices. I have started writing tests for the next update. But do you recommend TDD for iOS development?
In my experience it's useful to add a little more documentation/comments to your code. It makes it a lot more readable for anyone else and more importantly, a lot easier for yourself when you're writing updates a while from now. 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 tr…
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.
In my experience it's useful to add a little more documentation/comments to your code. It makes it a lot more readable for anyone else and more importantly, a lot easier for yourself when you're writing updates a while from now. 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 tr…
To illustrate, here's something I wrote not too long ago: https://gitlab.insomnia247.nl/coolfire/pfsense-ident-proxy/b... 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)
In my experience it's useful to add a little more documentation/comments to your code. It makes it a lot more readable for anyone else and more importantly, a lot easier for yourself when you're writing updates a while from now. 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 tr…
To illustrate, here's something I wrote not too long ago: https://gitlab.insomnia247.nl/coolfire/pfsense-ident-proxy/b... It's a little quick-and dirty but it's the way it's commented that makes the point I'm going for here.
Earlier quoted context omitted.
To illustrate, here's something I wrote not too long ago: https://gitlab.insomnia247.nl/coolfire/pfsense-ident-proxy/b... It's a little quick-and dirty but it's the way it's commented that makes the point I'm going for here.
Here's an example. You write: # 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 Don't do this (comment a block of code). 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 y…
Edit: Rather I should say; It's not always an option that makes things better.
If you're writing a comment for a block of code is definitely a good time to think "Should this not be a separate function?" (I clearly need to do this more myself too.)
Earlier quoted context omitted.
To illustrate, here's something I wrote not too long ago: https://gitlab.insomnia247.nl/coolfire/pfsense-ident-proxy/b... It's a little quick-and dirty but it's the way it's commented that makes the point I'm going for here.
I would say you're documenting way too much: the obvious shouldn't need documentation.