Hey Brian, been a long time viewer (since around 2k subs) and just wanted to say a huge thanks for sparking my interest in iOS dev. After watching your vids I shipped my first app to the app store and now have gotten my first internship offer to work at Apple doing iOS dev! Pumped for the future and wishing you all the best in your adventures :)
Great tip about the variable names. It takes extra time and can be difficult to read/understand code with single letter variable names. Also... same line braces, FTW!!!
Martin "Clean Code" is a great book for such purposes, even tho you sometimes have to adapt rules that it gives to modern swift conventions, but still most of the things remain the same
Most interviewers are going to be looking to make sure you code efficiently as well. So for example, if you have a table view and there's an image view that sometimes shows and sometimes doesn't, you'd want to use a UIStackView so that the image view only takes up actual memory when it's actually being used. You wouldn't want to just set the 'isHidden' property to true and hide it using some auto layout constraint. Speaking of auto layout....become an expert in it, both visual auto layout (using the storyboard) and how to programmatically create auto layout constraints as well. You also want to make sure you know how closures work, how memory management works (ARC, weak vs. strong references), as well as Swift language details (a struct vs. a class, value types vs reference types, inout function parameters and when they should be used, etc.)
Completely Worth 12 minutes .. Now eager for Next Video Describing what kind of projects to include in Portfolio >>> You are doing a great Work Brian !! Sharing what an iOS engineer from Silicon Valley does to entire world #iRespectYourWork
Depends what the job is asking for, you should include things relevant to that but show flexibility with slightly related to projects too. But if the job is something like bank security, you would show only encryption based apps and verification examples. Some jobs want no variance.
Awesome tips Brian! In 17 years of coding, I must say naming conventions is the most underrated skill. I like how you point out to stick to Swift and Apple's conventions. This is why you have very readable code and refactoring takes it another level.
Hey Brian, just wanted to say I have watched a lot of your videos and I picked up everything mentioned on this video simply by following your channel. Just want to say I really appreciate all your teachings!
For the first time in over 20 years; I am subscribing to (I do not know the name of what I am subscribing to) because this is an excellent, professionally executed video that is easy to understand and follow. Excellent voice clarity and quality, and concise informative content outperforms anything i have seen on the subject.
hi Brian, I just start learning Swift by watching your videos, really helps me a lot! if ok could you make a videos about what other skills(or knowledge) beginners need to know when they start iOS development?(except Swift)
One of the best practices I follow is creating extensions on Classes and declaring the protocol the class needs to conform to, such as UITableViewDatasource for example. It keeps the code more organized and clear as to what methods are being implemented to conform to that protocol. Ex: extension class ViewController: UITableViewDataSource { // required methods }
Awesome Brian, seems naming is really important. make sure I keep note of that. Looking forward to that next video, lol. Keep up the good work, #HappyCoding.
Hi Brian. Very nice video. But I have some proposals. I saw that you didn't use this scheme: class MyClass: UIViewController { // MARK: Constants .... // MARK: Variables .... // MARK: Lifecycle .... // MARK: Actions ..... } // MARK: UITableViewDelegate, UITableViewDataSource extension MyClass: UITableViewDelegate, UITableViewDataSource { ..... } I think that using MARK and extensions it's a very good practices.
I have mixed feelings about the clutter of the MARK comments. Having looked at code for so many years, it's pretty obvious what each section is doing. After a while, most engineers start to use search and find to look for code anyways.
Yup all good stuff and accurate! My current project also enforces self.varName or self.funcName on all global variables and functions in a file. Its also common to actually have a private struct Constants { static let randomUseHeight... } when necessary. OH yeah and a big one that I believe really looks better when reading code is space between { $0 + $1 } when using in line closures... so something like return self.allUserWishLists.value.filter { $0.items.first { $0.productIdentifier == savedItem.productIdentifier } != nil } Thanks again Brian for all your hard work and flood of great informative videos! would be nice to get some (more advanced) generics videos and maybe promise/future set up for reusability in api transactions in large projects
Another example I think is useful is to use the "// MARK: - Foo" to break up your larger classes into sections and help organize your files. Also I would have moved your setup methods below the viewDidLoad() in a "setup" section.
MARKs are a legacy thing from Objective-C. I'd recommend breaking up your classes into files that each have their own responsibility. You can do this with extensions, or by following a different architectural pattern such as MVVM or VIP.
I know it seems to be the latest fad to break out an extension for everything, but I find MARKs to be more readable. It keeps the class organized and more cohesive, and yet it's easy to navigate and well structured. I prefer to limit extensions to things like protocol conformance or extending a framework class. Objective-C has class extensions/categories, so I don't really think of MARKs as legacy--both have their place IMO.
Good stuff, Brian. My suggestions, as a defensive programmer, and with an eye to readability, clarity and long-term maintainability: Regarding the age property of your Person model, best practice would be to store the the birthdate instead, as a Date. This way, the age is always correct relative to the current date. Also, it only ever needs to be set once; it will never change, unlike "age". e.g. struct Person { let dateOfBirth: Date ... } On the matter of style and readability, I suggest that private and public be separated. Devs need some way to separate the private interface and code from the public. Traditionally, this is done with a leading underscore. e.g. var somePublicProperty: String var _somePrivateProperty: String func somePublicMethod() {...} fileprivate func _somePrivateMethod() {...} Free-standing Constants should be named as such. Traditionally in Cocoa, this is done with a leading "k". e.g. let kSomePublicConstant: String = "foo" let _kSomePrivateConstant: String = "bar" (A better solution is to encapsulate constants in to an Enum or Struct, as appropriate.) e.g. fileprivate struct _Appearance { static let defaultCellColor: UIColor = .red static let defaultCellHeight: CGFloat = 50 } ... cell.backgroundColor = _Appearance.defaultCellColor cell.setHeightOfThing(_Appearance.defaultCellHeight, animated: true) Regarding brace style, devs should use whatever brace style they prefer. Apple doesn't have just one brace style. Their sample code is all over the place, and Xcode 8's auto-systems are a joke. Choose your own brace style, but just be consistent. If you're on a team, write however you like, but lint the code so that it follows the team's guidelines when you commit it. For more info, I strongly suggest reading the bible of defensive programming: "Writing Solid Code". This is more than style or taste or religion; it's about basic usability. By using some kind of system like this, the programmer can see at a glance where a function/var/constant comes from, and where it doesn't. This saves a LOT of mental burden and time. You don't even have to option-click on symbols. Cheers.
Thanks for another great video!. In the future, would you please be able to create a video on iOS Architecture Patterns? I would be very interested in your feedback/experience working with different architecture patterns such as MVC, MVP, MVVM and VIPER etc. Thank you
I personally like using 2 spaces for tab spacing instead of the usual 4 space. When I did web dev during a summer internship, a fellow intern recommended using 2 spaces and it made the code look clean and compact. Now I always set tab spacing as 2 in all of my IDE!
Yeah spacing is another big convention that folks seem to have a debate about. I like to keep the spacing to whatever the IDE defaults it to be, this way whenever I move from machine to machine or reinstalls I only have a minimal of things to change.
Nice video with some great tips for beginners, Brian! A little nitpicky, but I would put viewDidLoad() above the setup functions. For me, I think viewDidLoad(), init(), viewWillAppear(), etc should have top priority in the file since that is where the magic happens and it makes it easier to understand what the ViewController does. Just my opinion.
Just a little confused about 'var products: [String]? = ["iPhone", "iPad"]' Would it be better to write it as 'let products = ["iPhone", "iPad"] My thought process being that it would infer the type based on the data you have in the array? The let to var part may not be applicable if you decide to change the array and I'm assuming it would also be set to nil at some point ?
But there's two very different things here. The first line is an Optional of subtype [String]. The second example is a constant array of Strings. The first is required where both mutability and Optionality are required. The second is needed when the list of products is fixed for all time.
I am programming for about 40 years now and most of your conventions are ok. However we have to point out that certain conventions exist since ever: - short variable names indicate a local use of no importance, such as loop counters called i. Same goes for strings from a to h. - braces start at a new line because of readability. If you browse a lot of code for searching a specific piece, your brain gives up on mixed entrances. It's a question of mind efficiency. I can run a program at full speed on my screen and spot the place where to make a change, while with Apple convention I have to single step through and still have difficulties to find stuff. Since you point out the importance of separate functions, please ask your mind, why. The reason is graphic separation and ease to read.
Great tip for new programmers with your Person struct age variable. One thing you didnt mention is that a Double age could never be tested for equality with a value since Doubles are only binary approximations of decimal real numbers. So checking for age == 65.0 would probably always fail in your code. But anyway, great video! Think of any other practices to follow?
Awesome video! one question, do you have to create your own code during an interview or they just want to see an example of mine? thanks in advance! :)
Generally they provide you a small problem and follow you while you develop a solution. This does not mean you need to be able to know how to resolve the problem, they want to see if you are able to reason or even look for clues on internet or with other people. If you think about it, what IS a good developer? someone that already knows everything (not possible), or someone that is able to find ways to solve problems through study and collaboration? At least this is what i had to do in an interview.
Here's a nice and easy example of what I consider good code, I'm gonna refer to c# but gonna try to keep it general. You have a class, each time you instantiate an object of that class, it's constructor runs, you have to initialize a variable so a particular method/function can access it when it's called, it can't be static, the assignment let's say have to test something and sign a true or false, so it's different for each object, let's say this method accessing the variable is called when you click a button, and let's say there's many objects being instantiated at the start of the program. So the choice is this, you can initialize the variable in the constructor or at the start of the method itself. The program runs exactly the same either way, except for one thing, the time complexity. You could initialize the variable in the constructor, but what if you have a billion objects ? The time complexity would be O(N), a billion assignments at the start of the code, this would halt the execution until it's done. But if you put this assignment at the start of the method itself, when it's called, thus the variable will be ready when it's needed, so, when you actually click a button, the time complexity would be O(1), best case scenario, would work exactly the same but that would be some awesome code. Of course I'm exaggerating with the billion object example just to prove a point.
You should use birthdate and not age. If that info is stored (login data or whatever) then you will not have an accurate age of the person. And if the person is willing to tell his/her age, always ask for birthdate. With birthdate you can alway show age, but newer the other way around.
Thank you very much sir for all your videos. They are always short and simple. Few things I wanted to learn. If you can make some videos on it. I use pods in my projects all the time and use git repositories into my project. 1. First how can we reduce the size of our project. Which was effected by the git file. 2. Second when we use pods into one project and then if we use same pods for other projects then is there any way that we can do it with just simply drag and dropping the old files into new pods project ? I was working as IOS developer from last 4 year. But still most of the time I took more time to develop the things from my estimated time this is something I guess nobody can teach to any one but if you can give us some tips. Using which we can save our time and finish our work within the time.
Your voice is crystal clear and front camera is good, but why your all videos have blurred, hazy, misty pictures. I have subscribed to your channel and this is with your all videos.
Great video! I just found your channel today and have watched 4 or 5 of your videos so far. Have you read the book Clean Code by Robert Martin? If not I would definitely reccommend it, you cover a few of the topics mentioned. I found it a few years ago and reccommend it to everyone I meet the programs regardless of language.
I think that instead of registering cells in the view controllers, might as well make use of the xib or storyboard. It's a fine line that UI elements as much as possible should stay in the interface builder.
Thanks for this! I will be graduating university in December and I look for every bit of advice I can regarding getting a software development position. Can you please do that video on projects that are good to have in a portfolio?
Thanks so much for posting this video, it was very helpful for me as a beginner coder - sorry if this is a dumb question but I was wondering what software you are using in the video, to do the coding?
Just to add, when naming a variable in all uppercase it's usually to signify that it is a constant one, meaning the value you assign to it will not change further in the program, this can be useful for such things like 1.6km for every mile or a customers date of birth will always be 1980, etc.
I believe the convention of all caps for variables are not present in the Swift language. Instead we are encouraged to use things like kVideoType, or an actual enum.
Yeah my bad, i'm just a C#/Java noob honestly (lol), I find teaching is the best way to retain information and understand a subject better. Also I have just found your video I believe it was what programming languages to learn video, decided to pick up Python but thank you, your videos are clear to understand.
When I verify a candidate code I want to see: code which follows populars conventions like ray wenderlich(can find it on github) design patterns(MVVM > MVC) Dependency Injection(don't need to use frameworks here) SOLID principles DRY(Don't repeat yourself) "consistent code" for example if you use C style brackets thats ok but use it everywhere, instead of in class A - C style, in class B - java style etc. More smaller methods and classes > less bigger methods and classes using protocol oriented programming unit tests using extensions no retain cycles dont use global variables or passing data by UserDefaults(this is very wrong and unfortunately very popular!!!!) I know junior developers can't follow all these rules unless they are very talented. ;) Of course these rules are important for me and can be wrong for some others interviewers.
The conventional way of passing data from view to controller is to use something called Custom Delegation, which is just a fancy word for setting up a protocol method that you can call from one class to another. If you're really interested in a full lesson, you can check out this video that's part of our Instagram Firebase course: www.letsbuildthatapp.com/course_video?id=1502
Good video! Thank you so much for not mentioning SOLID, Clean Code, or any of the other crap that plagues the industry. One disagreement though, if you are interested: Chopping up a function into smaller functions for no purpose (such as separating logic from action) doesn't automatically make things easier to read. OOP already has you hopping around finding methods all over the place. Think of eating starburst. Wouldn't it be nice to just have the whole candy bar in one place, instead of having to unwrap tightly bound individual pieces of small candy? Having to keep many methods in your memory like doStuff() doMoreStuff() and so on makes your code HARDER to reason about, because you have to keep it all in working memory, instead of just reading top to bottom. And, then you have a bunch of tiny methods cluttering up your class that are only used in one place. I think a much better approach to simple doStuff() methods like the ones you created, where logic isn't involved, is to just put a comment line // Create collectionView ... or wrap it in a `do {` block. Or, put the func declaration inside of VDL, instead of outside, where it is cluttering your class. Now you have everything in one place, collapsible, described, and aren't cluttering up your class with tiny methods that are only used in one place.
There is some debate against multiple methods, but for the most part almost all companies have small functions. To confirm this, you can look through their open source code. My example was probably too trivial, I really meant to describe a situation such as: 1. Downloading a json file 2. Sending the information back to controller via a completion block Usually I'll see all this code in one single method which is messy.
This is often a very debatable topic. While it doesn't affect performance at all, I wouldn't want to work with a total diva that doesn't follow company standards. For personal projects, we're all free to do what we want.
Hey amazing video. I`d also like to ask your something, when i make a model like you did in the video, I like to use class over struct and inherit from "NSObject" the reason i do that is because there are some protocols that you might need to confirm to manually while using struct. For example: "the equitable protocol" which i needed in order to use ".index(of: )" method. Just wanna know your view on that. thnx :)
I used to think this way too but working with very long codes, I realized that declaring variables close to where they are actually being used seems better. Of course, there are exceptions to this. Like variables that are used all over the class/method/controllers should still be declared at the top.
Hi Brian in relation to Age : Double / Int... Doubles are 64 bit and Float 32 bit, Int is the processing size of the default device word so for iPhones after 5S they are 64 bit.... Back in the day of 8 bit processing you are correct (Doubles being 5 times larger than Ints). Love your work though !
I've been taught to utilize DRY coding as much as possible. It certainly helps in creating concise and clean code that is both easy to read and debug. Would love to know your thoughts!
Indeed, in all of my tutorials you'll see really clean coding practices and I'll throw in how to refactor code to improve maintainability as well. Hope you've seen them in my courses too.
Hello Brian, I am new to iOS programming and I am a big fan of your videos and would love to connect to the community you have built. I have sent a join request on Facebook. Please accept. Thanks a lot for your time to make such awesome tutorials for us to learn from.
Hi Brian! I do my big project like you all in code. I done build all UI. And now have problem how to realize get data from Firebase (I know how to get data), but want to do this more 'beautiful' and show informations in app. What architecture to use? MVC? MVP? MVVM? And how to do this? Or can you make video about refactoring code? Thank you for videos.
I would say that a 'let' variable should be upper case such as PET_NAME and a 'var' would be camel case such as petAge. This way, it is easy to see what is a constant and what is a variable. Also, private variables, I would start with '__'. For example, 'let __password == "password"'. Constant: Uppercase Variable: camelCase Private: Two underscores at the beginning.
In Cocoa, traditionally, all-upper-case constants are rarely used, and when they are they're typically reserved for the global space, and for important, configuration constants. e.g. kENABLE_DEBUG_MODE You don't want this kind of thing all through your code. OTHERWISE_MUCH_OF_YOUR_CODE_WOULD_LOOK_LIKE_THIS IT'S_VERY_TIRING_TO_READ_ISNT_IT. If you want to mark your constants, and IMO you should, then consider the "k". e.g. let kPi: CGFloat = 3.14 let kFileName: String = "Data.json" etc. I agree on private naming, for everything. e.g. fileprivate var _LastUserName: String = "Foo" fileprivate let _kFileName: String = Data.json" fileprivate func _setup() { ... } fileprivate struct _Config { let navBarColor: UIColor = .red .... }
Thanks for the Tim. Adding 'k' does make it look neater. Its just because I normally program everything in the same style no matter what the language is (I sometimes re-write the pre-generated code to my style). For example, I hate the C# format in Xamarin where it uses an underscore instead of camel case.
@TheComputerPerson my suggestion is "don't fight the platform". Using one platform's conventions on another rarely works well. In the case of Cocoa and Swift, that means lowerCamelCase for variables and methods, and UpperCamelCase for Types. Underscores are used, but only at the start of a name, indicating private variables/methods/types. e.g. 'var _myPrivateVar: Int' If most professional Cocoa coders see stuff like "my_private_var" or "SOME_CONSTANT", they will either lint your code or simply not use your code. It's not just about style or preference; it's about fitting in with the existing system with the least amount of friction.
Another great video! 👍 When are you going to show us Android development? Can't wait for that. At least can you show us first how to set it up for the environment? I have checked couple tutorials but was very confused with the Path settings etc. Thank you a lot!
Yes, all caps for constants still lives strong in Java as well. I would stay away from this naming convention though as its not used in the Swift community.
The splitting up of a function, should not be about the length but about function. So I agree you should split that function up, but not because it is long, but because it contains two different aspects of setups.
Recruiter that are interested in coding/naming convention are bad at their job, unless the interviewee has already proven to be very good, but in this case I think you can just hire the guy based on how nice he seems to be. What you need is someone that can solve problems, if you have to interview someone, just give him/her a really hard set of problems and look how he/she handles it. If you hire someone that can solve hard problems, for sure he/she will be able to learn (your) coding conventions in a day or so. Even if you ask them simple problems, there are stuff that you can watch way before looking at such superficial stuff as conventions (by definition, a conventions are not good or bad, they're just an agreement whereas a candidate can be good or bad, and this can be measured very efficiently). Even asking questions about a given langage seems ridiculous to me, especially because most of the popular langages used today are pretty simple to learn (they are designed to be). You could talk about computer architecture (memory in particular), complexity or even maths. All of these are way more important than any langage feature. You would be surprised how many people have poor knowledge in one of these three important things.
If only this would be so easy, I've been doing a looooot of tests and everytime companies don't like something - whether its (not) following certain architecture style, (not) using certain 3rd party libs, (not) having comments, etc.
Hello Eyad, you can checkout the Instagram Firebase course at www.letsbuildthatapp.com/course/instagram-firebase. We go through a bunch of good lessons on how to get the UI hooked up with Firebase. Good luck.
Thanks a lot for tutorial :) so could you please make a tutorial about MVC on Swift if you not mind :) I really really want to know how to make an app with the clean code :) Thank you, appreciate
Hey Brian, been a long time viewer (since around 2k subs) and just wanted to say a huge thanks for sparking my interest in iOS dev. After watching your vids I shipped my first app to the app store and now have gotten my first internship offer to work at Apple doing iOS dev! Pumped for the future and wishing you all the best in your adventures :)
Great tip about the variable names. It takes extra time and can be difficult to read/understand code with single letter variable names. Also... same line braces, FTW!!!
wow, Sean Allen is also an awesome Swift/Apple tech guy, you both great!
Thanks for the kind words Jonney!
It's really nice to see Sean Allen here. Thank you guys for sharing your knowledge with us. God bless you.
what is file private func sean??
Thank you so much for making this video! I am much more comfortable now preparing for my interviews. Absolutely incredible resource!
+Casey West you are very welcome, hope to answer more questions in he future
Martin "Clean Code" is a great book for such purposes, even tho you sometimes have to adapt rules that it gives to modern swift conventions, but still most of the things remain the same
This is actually quite useful to know what teams are looking for and to go over things after you've written them. Thanks!
I am really glade my school emphasized all those conventions as I follow each one :) Nice work!
Please more of these coding conventions!!
Great tutorial!
Clean coding is the key! 12 minutes and 35 seconds which every developer should spend to watch this video! thanks for your videos.
Happy you found all 12 mins and 35 seconds entertaining and useful for your development journey.
Most interviewers are going to be looking to make sure you code efficiently as well. So for example, if you have a table view and there's an image view that sometimes shows and sometimes doesn't, you'd want to use a UIStackView so that the image view only takes up actual memory when it's actually being used. You wouldn't want to just set the 'isHidden' property to true and hide it using some auto layout constraint.
Speaking of auto layout....become an expert in it, both visual auto layout (using the storyboard) and how to programmatically create auto layout constraints as well.
You also want to make sure you know how closures work, how memory management works (ARC, weak vs. strong references), as well as Swift language details (a struct vs. a class, value types vs reference types, inout function parameters and when they should be used, etc.)
Completely Worth 12 minutes .. Now eager for Next Video Describing what kind of projects to include in Portfolio >>> You are doing a great Work Brian !! Sharing what an iOS engineer from Silicon Valley does to entire world #iRespectYourWork
Depends what the job is asking for, you should include things relevant to that but show flexibility with slightly related to projects too. But if the job is something like bank security, you would show only encryption based apps and verification examples. Some jobs want no variance.
Awesome tips Brian! In 17 years of coding, I must say naming conventions is the most underrated skill. I like how you point out to stick to Swift and Apple's conventions. This is why you have very readable code and refactoring takes it another level.
Hey Brian, just wanted to say I have watched a lot of your videos and I picked up everything mentioned on this video simply by following your channel. Just want to say I really appreciate all your teachings!
For the first time in over 20 years; I am subscribing to (I do not know the name of what I am subscribing to) because this is an excellent, professionally executed video that is easy to understand and follow. Excellent voice clarity and quality, and concise informative content outperforms anything i have seen on the subject.
+jaimexctsg is this spam?
Yup, I agree with all these tips as best coding practices
Hi Brian: Excellent review. Very valuable (as usual)!
hi Brian, I just start learning Swift by watching your videos, really helps me a lot! if ok could you make a videos about what other skills(or knowledge) beginners need to know when they start iOS development?(except Swift)
One of the best practices I follow is creating extensions on Classes and declaring the protocol the class needs to conform to, such as UITableViewDatasource for example. It keeps the code more organized and clear as to what methods are being implemented to conform to that protocol. Ex: extension class ViewController: UITableViewDataSource { // required methods }
I follow all that coding practices. But is nice to see I'm in the right path.
Thanks for your videos.
Awesome Brian, seems naming is really important. make sure I keep note of that. Looking forward to that next video, lol. Keep up the good work, #HappyCoding.
Man, the next episode will be AMAZING !!!!!
Hi Brian. Very nice video. But I have some proposals. I saw that you didn't use this scheme:
class MyClass: UIViewController {
// MARK: Constants
....
// MARK: Variables
....
// MARK: Lifecycle
....
// MARK: Actions
.....
}
// MARK: UITableViewDelegate, UITableViewDataSource
extension MyClass: UITableViewDelegate, UITableViewDataSource {
.....
}
I think that using MARK and extensions it's a very good practices.
I have mixed feelings about the clutter of the MARK comments. Having looked at code for so many years, it's pretty obvious what each section is doing. After a while, most engineers start to use search and find to look for code anyways.
Yup all good stuff and accurate! My current project also enforces self.varName or self.funcName on all global variables and functions in a file. Its also common to actually have a private struct Constants { static let randomUseHeight... } when necessary. OH yeah and a big one that I believe really looks better when reading code is space between { $0 + $1 } when using in line closures... so something like return self.allUserWishLists.value.filter { $0.items.first { $0.productIdentifier == savedItem.productIdentifier } != nil }
Thanks again Brian for all your hard work and flood of great informative videos! would be nice to get some (more advanced) generics videos and maybe promise/future set up for reusability in api transactions in large projects
Another example I think is useful is to use the "// MARK: - Foo" to break up your larger classes into sections and help organize your files.
Also I would have moved your setup methods below the viewDidLoad() in a "setup" section.
Yep plenty of improvements, not enough time to go through all of them. Perhaps in a part #2 video.
MARKs are a legacy thing from Objective-C. I'd recommend breaking up your classes into files that each have their own responsibility. You can do this with extensions, or by following a different architectural pattern such as MVVM or VIP.
I know it seems to be the latest fad to break out an extension for everything, but I find MARKs to be more readable. It keeps the class organized and more cohesive, and yet it's easy to navigate and well structured. I prefer to limit extensions to things like protocol conformance or extending a framework class.
Objective-C has class extensions/categories, so I don't really think of MARKs as legacy--both have their place IMO.
Good stuff, Brian.
My suggestions, as a defensive programmer, and with an eye to readability, clarity and long-term maintainability:
Regarding the age property of your Person model, best practice would be to store the the birthdate instead, as a Date. This way, the age is always correct relative to the current date. Also, it only ever needs to be set once; it will never change, unlike "age".
e.g.
struct Person {
let dateOfBirth: Date
...
}
On the matter of style and readability, I suggest that private and public be separated. Devs need some way to separate the private interface and code from the public.
Traditionally, this is done with a leading underscore. e.g.
var somePublicProperty: String
var _somePrivateProperty: String
func somePublicMethod() {...}
fileprivate func _somePrivateMethod() {...}
Free-standing Constants should be named as such. Traditionally in Cocoa, this is done with a leading "k". e.g.
let kSomePublicConstant: String = "foo"
let _kSomePrivateConstant: String = "bar"
(A better solution is to encapsulate constants in to an Enum or Struct, as appropriate.)
e.g.
fileprivate struct _Appearance
{
static let defaultCellColor: UIColor = .red
static let defaultCellHeight: CGFloat = 50
}
...
cell.backgroundColor = _Appearance.defaultCellColor
cell.setHeightOfThing(_Appearance.defaultCellHeight, animated: true)
Regarding brace style, devs should use whatever brace style they prefer. Apple doesn't have just one brace style. Their sample code is all over the place, and Xcode 8's auto-systems are a joke. Choose your own brace style, but just be consistent. If you're on a team, write however you like, but lint the code so that it follows the team's guidelines when you commit it.
For more info, I strongly suggest reading the bible of defensive programming: "Writing Solid Code".
This is more than style or taste or religion; it's about basic usability. By using some kind of system like this, the programmer can see at a glance where a function/var/constant comes from, and where it doesn't. This saves a LOT of mental burden and time. You don't even have to option-click on symbols.
Cheers.
Thanks for the tips! Recently graduated with a degree in CpE and will use these tips during the interview process!!
Thanks for another great video!. In the future, would you please be able to create a video on iOS Architecture Patterns?
I would be very interested in your feedback/experience working with different architecture patterns such as MVC, MVP, MVVM and VIPER etc.
Thank you
Very helpful! I hope there gonna be a part 2.
I'm thinking about addressing other common rookie mistakes that I find during code reviews.
I personally like using 2 spaces for tab spacing instead of the usual 4 space. When I did web dev during a summer internship, a fellow intern recommended using 2 spaces and it made the code look clean and compact. Now I always set tab spacing as 2 in all of my IDE!
Yeah spacing is another big convention that folks seem to have a debate about. I like to keep the spacing to whatever the IDE defaults it to be, this way whenever I move from machine to machine or reinstalls I only have a minimal of things to change.
iOS projects default to 4 spaces, so if you work with a team you should use the default unless you've previously agreed on 2.
Nice video with some great tips for beginners, Brian!
A little nitpicky, but I would put viewDidLoad() above the setup functions. For me, I think viewDidLoad(), init(), viewWillAppear(), etc should have top priority in the file since that is where the magic happens and it makes it easier to understand what the ViewController does. Just my opinion.
in breaking up code.. always think about Single responsibility principle..
This is an excellent point, I wish schools would teach this principle.
Great video ! The interview process is so hard and really frustrating.What tips would you give to tackle coding questions
Thanks for this! your video is so easy to follow!
Just a little confused about
'var products: [String]? = ["iPhone", "iPad"]'
Would it be better to write it as
'let products = ["iPhone", "iPad"]
My thought process being that it would infer the type based on the data you have in the array? The let to var part may not be applicable if you decide to change the array and I'm assuming it would also be set to nil at some point ?
Excellent catch, I was going to go through this example but went to sleep instead :)
Lets Build That App :) loved the video btw
But there's two very different things here. The first line is an Optional of subtype [String]. The second example is a constant array of Strings. The first is required where both mutability and Optionality are required. The second is needed when the list of products is fixed for all time.
Glad you found the easter egg.
keeping curly brace on the same line decreases total number of code in your project. excellent tutorial ... keep it up
This is amazing and very useful for beginners. I'll be back later for some great stuff.
I am programming for about 40 years now and most of your conventions are ok. However we have to point out that certain conventions exist since ever:
- short variable names indicate a local use of no importance, such as loop counters called i. Same goes for strings from a to h.
- braces start at a new line because of readability. If you browse a lot of code for searching a specific piece, your brain gives up on mixed entrances. It's a question of mind efficiency. I can run a program at full speed on my screen and spot the place where to make a change, while with Apple convention I have to single step through and still have difficulties to find stuff. Since you point out the importance of separate functions, please ask your mind, why. The reason is graphic separation and ease to read.
40?...damn
Great tip for new programmers with your Person struct age variable. One thing you didnt mention is that a Double age could never be tested for equality with a value since Doubles are only binary approximations of decimal real numbers. So checking for age == 65.0 would probably always fail in your code. But anyway, great video! Think of any other practices to follow?
Awesome video!
one question, do you have to create your own code during an interview or they just want to see an example of mine?
thanks in advance! :)
Generally they provide you a small problem and follow you while you develop a solution.
This does not mean you need to be able to know how to resolve the problem, they want to see if you are able to reason or even look for clues on internet or with other people.
If you think about it, what IS a good developer? someone that already knows everything (not possible), or someone that is able to find ways to solve problems through study and collaboration?
At least this is what i had to do in an interview.
ok, thank you for answering my question :)
Thank you for sharing valuable points. Please continue to upload more n more videos.
Here's a nice and easy example of what I consider good code, I'm gonna refer to c# but gonna try to keep it general.
You have a class, each time you instantiate an object of that class, it's constructor runs, you have to initialize a variable so a particular method/function can access it when it's called, it can't be static, the assignment let's say have to test something and sign a true or false, so it's different for each object, let's say this method accessing the variable is called when you click a button, and let's say there's many objects being instantiated at the start of the program.
So the choice is this, you can initialize the variable in the constructor or at the start of the method itself. The program runs exactly the same either way, except for one thing, the time complexity.
You could initialize the variable in the constructor, but what if you have a billion objects ? The time complexity would be O(N), a billion assignments at the start of the code, this would halt the execution until it's done.
But if you put this assignment at the start of the method itself, when it's called, thus the variable will be ready when it's needed, so, when you actually click a button, the time complexity would be O(1), best case scenario, would work exactly the same but that would be some awesome code.
Of course I'm exaggerating with the billion object example just to prove a point.
Cool, I am already following all these conventions♥️😍
Very informative , now i will keep these tips in my mind during code
You should use birthdate and not age. If that info is stored (login data or whatever) then you will not have an accurate age of the person. And if the person is willing to tell his/her age, always ask for birthdate. With birthdate you can alway show age, but newer the other way around.
Oh, nice videos by the way. Calm voice and you stick to the point. Thumbs up.
+RnRoadkills kind words appreciated. Trying my best to keep these videos entertaining and informative at the same time
Thank you very much sir for all your videos. They are always short and simple. Few things I wanted to learn. If you can make some videos on it. I use pods in my projects all the time and use git repositories into my project.
1. First how can we reduce the size of our project. Which was effected by the git file.
2. Second when we use pods into one project and then if we use same pods for other projects then is there any way that we can do it with just simply drag and dropping the old files into new pods project ?
I was working as IOS developer from last 4 year. But still most of the time I took more time to develop the things from my estimated time this is something I guess nobody can teach to any one but if you can give us some tips. Using which we can save our time and finish our work within the time.
Great Video. Thank you for posting. This was informative and helpful.
In Swift both Int and Double are 64 bits. There's plenty of reasons for choosing Int over Double, but memory size isn't one of them.
Your voice is crystal clear and front camera is good, but why your all videos have blurred, hazy, misty pictures. I have subscribed to your channel and this is with your all videos.
Subscribed. I'm learning Csharp but this will come in handy
Not a swift developer, but these principles are universal!
Great video! I just found your channel today and have watched 4 or 5 of your videos so far.
Have you read the book Clean Code by Robert Martin? If not I would definitely reccommend it, you cover a few of the topics mentioned.
I found it a few years ago and reccommend it to everyone I meet the programs regardless of language.
I think that instead of registering cells in the view controllers, might as well make use of the xib or storyboard. It's a fine line that UI elements as much as possible should stay in the interface builder.
+puhgeh you’ll find that Interface Builder slows you down the better you get at coding
Thanks for this! I will be graduating university in December and I look for every bit of advice I can regarding getting a software development position. Can you please do that video on projects that are good to have in a portfolio?
Really great video. Could you also make a video tutorial for explaining UIScrollView UIImageView & CALayer and about UIGestureRecognizer.
Thanks so much for posting this video, it was very helpful for me as a beginner coder - sorry if this is a dumb question but I was wondering what software you are using in the video, to do the coding?
chimo chan coding for macOS/iOS/etc is done in xCode
Nice explain standard coding Yeah, I did like this. it is not difficult give variable name
Just to add, when naming a variable in all uppercase it's usually to signify that it is a constant one, meaning the value you assign to it will not change further in the program, this can be useful for such things like 1.6km for every mile or a customers date of birth will always be 1980, etc.
I believe the convention of all caps for variables are not present in the Swift language. Instead we are encouraged to use things like kVideoType, or an actual enum.
Yeah my bad, i'm just a C#/Java noob honestly (lol), I find teaching is the best way to retain information and understand a subject better. Also I have just found your video I believe it was what programming languages to learn video, decided to pick up Python but thank you, your videos are clear to understand.
When I verify a candidate code I want to see:
code which follows populars conventions like ray wenderlich(can find it on github)
design patterns(MVVM > MVC)
Dependency Injection(don't need to use frameworks here)
SOLID principles
DRY(Don't repeat yourself)
"consistent code" for example if you use C style brackets thats ok but use it everywhere, instead of in class A - C style, in class B - java style etc.
More smaller methods and classes > less bigger methods and classes
using protocol oriented programming
unit tests
using extensions
no retain cycles
dont use global variables or passing data by UserDefaults(this is very wrong and unfortunately very popular!!!!)
I know junior developers can't follow all these rules unless they are very talented. ;) Of course these rules are important for me and can be wrong for some others interviewers.
+Mateusz Mirkowski these are all excellent things to look for in sample code, and also interesting discussion points for the interview
What is recommended for passing data in you opinion? I use UserDefaults for that for my IAPs... works fine but probably wrong then? :)
The conventional way of passing data from view to controller is to use something called Custom Delegation, which is just a fancy word for setting up a protocol method that you can call from one class to another. If you're really interested in a full lesson, you can check out this video that's part of our Instagram Firebase course: www.letsbuildthatapp.com/course_video?id=1502
Great video man! Am I the only one that thinks you look like the younger Andrew Ng??
I think he's a lot sexier.
Good video! Thank you so much for not mentioning SOLID, Clean Code, or any of the other crap that plagues the industry.
One disagreement though, if you are interested:
Chopping up a function into smaller functions for no purpose (such as separating logic from action) doesn't automatically make things easier to read. OOP already has you hopping around finding methods all over the place.
Think of eating starburst. Wouldn't it be nice to just have the whole candy bar in one place, instead of having to unwrap tightly bound individual pieces of small candy? Having to keep many methods in your memory like doStuff() doMoreStuff() and so on makes your code HARDER to reason about, because you have to keep it all in working memory, instead of just reading top to bottom. And, then you have a bunch of tiny methods cluttering up your class that are only used in one place.
I think a much better approach to simple doStuff() methods like the ones you created, where logic isn't involved, is to just put a comment line // Create collectionView ... or wrap it in a `do {` block. Or, put the func declaration inside of VDL, instead of outside, where it is cluttering your class.
Now you have everything in one place, collapsible, described, and aren't cluttering up your class with tiny methods that are only used in one place.
There is some debate against multiple methods, but for the most part almost all companies have small functions. To confirm this, you can look through their open source code. My example was probably too trivial, I really meant to describe a situation such as:
1. Downloading a json file
2. Sending the information back to controller via a completion block
Usually I'll see all this code in one single method which is messy.
In my UNIX scripting days I only converted code into functions if it was needed to be called more than once...
u are amazing thanks for the video .
Trust me, everyone loves Maintainable and Modular code!
If a company marks you for not following same line brace or even the latter: you're probably better off not working for them
This is often a very debatable topic. While it doesn't affect performance at all, I wouldn't want to work with a total diva that doesn't follow company standards. For personal projects, we're all free to do what we want.
Nice one. thank you
please upload video about design pattern and how to implement in code. I am looking for that.
Thanks for this video and more power such a helpful video for a student like me.
Hey amazing video. I`d also like to ask your something, when i make a model like you did in the video, I like to use class over struct and inherit from "NSObject" the reason i do that is because there are some protocols that you might need to confirm to manually while using struct. For example: "the equitable protocol" which i needed in order to use ".index(of: )" method.
Just wanna know your view on that. thnx :)
Your variables should be at the top. I would hate to maintain your code with all the 'let' found in random places in the middle.
Yes, unfortunately there is only so much you can show/do in a video recording before it gets too confusing.
Variables should be declared as close to their usage as possible. The exception being classes.
I used to think this way too but working with very long codes, I realized that declaring variables close to where they are actually being used seems better. Of course, there are exceptions to this. Like variables that are used all over the class/method/controllers should still be declared at the top.
Hi Brian in relation to Age : Double / Int... Doubles are 64 bit and Float 32 bit, Int is the processing size of the default device word so for iPhones after 5S they are 64 bit.... Back in the day of 8 bit processing you are correct (Doubles being 5 times larger than Ints). Love your work though !
This what I needed. Thanks
I've been taught to utilize DRY coding as much as possible. It certainly helps in creating concise and clean code that is both easy to read and debug. Would love to know your thoughts!
Indeed, in all of my tutorials you'll see really clean coding practices and I'll throw in how to refactor code to improve maintainability as well. Hope you've seen them in my courses too.
hey Brian what do you think of the new Fuchsia OS that Google is working on. do you know if that's got any potential?
Thanks for the video, i love you Brian..
Hello Brian, I am new to iOS programming and I am a big fan of your videos and would love to connect to the community you have built. I have sent a join request on Facebook. Please accept. Thanks a lot for your time to make such awesome tutorials for us to learn from.
Hi Brian! I do my big project like you all in code. I done build all UI. And now have problem how to realize get data from Firebase (I know how to get data), but want to do this more 'beautiful' and show informations in app. What architecture to use? MVC? MVP? MVVM? And how to do this? Or can you make video about refactoring code? Thank you for videos.
I would say that a 'let' variable should be upper case such as PET_NAME and a 'var' would be camel case such as petAge. This way, it is easy to see what is a constant and what is a variable. Also, private variables, I would start with '__'. For example, 'let __password == "password"'.
Constant: Uppercase
Variable: camelCase
Private: Two underscores at the beginning.
In Cocoa, traditionally, all-upper-case constants are rarely used, and when they are they're typically reserved for the global space, and for important, configuration constants.
e.g. kENABLE_DEBUG_MODE
You don't want this kind of thing all through your code. OTHERWISE_MUCH_OF_YOUR_CODE_WOULD_LOOK_LIKE_THIS IT'S_VERY_TIRING_TO_READ_ISNT_IT.
If you want to mark your constants, and IMO you should, then consider the "k". e.g.
let kPi: CGFloat = 3.14
let kFileName: String = "Data.json"
etc.
I agree on private naming, for everything.
e.g.
fileprivate var _LastUserName: String = "Foo"
fileprivate let _kFileName: String = Data.json"
fileprivate func _setup() { ... }
fileprivate struct _Config
{
let navBarColor: UIColor = .red
....
}
Thanks for the Tim. Adding 'k' does make it look neater. Its just because I normally program everything in the same style no matter what the language is (I sometimes re-write the pre-generated code to my style). For example, I hate the C# format in Xamarin where it uses an underscore instead of camel case.
@TheComputerPerson my suggestion is "don't fight the platform". Using one platform's conventions on another rarely works well. In the case of Cocoa and Swift, that means lowerCamelCase for variables and methods, and UpperCamelCase for Types. Underscores are used, but only at the start of a name, indicating private variables/methods/types. e.g. 'var _myPrivateVar: Int'
If most professional Cocoa coders see stuff like "my_private_var" or "SOME_CONSTANT", they will either lint your code or simply not use your code.
It's not just about style or preference; it's about fitting in with the existing system with the least amount of friction.
Thanks for the that. I shall do that next time then. Its just because I hate the C# formatting which_is_like_this iPreferCammelCaseInstead.
Another great video! 👍
When are you going to show us Android development? Can't wait for that. At least can you show us first how to set it up for the environment? I have checked couple tutorials but was very confused with the Path settings etc. Thank you a lot!
Just posted my comment and then spotted this directly after. BRIAN, YOU HAVE BEEN SUMMONED!
Finger crossed!🤞
I think the all caps for constants is a throw back to C++ where it was common practice to use all caps for constants.
Yes, all caps for constants still lives strong in Java as well. I would stay away from this naming convention though as its not used in the Swift community.
What are the best conventions for access levels such as private, fileprivate, public, etc. ?
In 64bit architectures, swift Int is 64 bits, just like Double
The splitting up of a function, should not be about the length but about function. So I agree you should split that function up, but not because it is long, but because it contains two different aspects of setups.
Bevan Jones i think is better to have a lot of func that one large one.
I was told that if my func is more that 10 lines I should try to split them.
Great video, as always ! Can we have now a similar video for Android Dev, please !?
Great video - thanks!
Recruiter that are interested in coding/naming convention are bad at their job, unless the interviewee has already proven to be very good, but in this case I think you can just hire the guy based on how nice he seems to be. What you need is someone that can solve problems, if you have to interview someone, just give him/her a really hard set of problems and look how he/she handles it.
If you hire someone that can solve hard problems, for sure he/she will be able to learn (your) coding conventions in a day or so.
Even if you ask them simple problems, there are stuff that you can watch way before looking at such superficial stuff as conventions (by definition, a conventions are not good or bad, they're just an agreement whereas a candidate can be good or bad, and this can be measured very efficiently). Even asking questions about a given langage seems ridiculous to me, especially because most of the popular langages used today are pretty simple to learn (they are designed to be).
You could talk about computer architecture (memory in particular), complexity or even maths. All of these are way more important than any langage feature.
You would be surprised how many people have poor knowledge in one of these three important things.
Pretty good insight !!
Point taken but ... on a 64-bit platform, Int is the same size as Double.
Exactly on 64 bits machine, they are both 64 bits.
Great video. Thanks.
I didn't knew that I was already following these rules
Great job, must've had a good mentor.
If only this would be so easy, I've been doing a looooot of tests and everytime companies don't like something - whether its (not) following certain architecture style, (not) using certain 3rd party libs, (not) having comments, etc.
What do u think about Moya library ?
Can u take a video about moya ?
Storyboards and/or XIBs.
Thanks for the video.
Do you have classes for iOS dev online that I can take with you? And if not which classes for iOS dev do you recommend for me to take ? Thanks
Hello Eyad, you can checkout the Instagram Firebase course at www.letsbuildthatapp.com/course/instagram-firebase. We go through a bunch of good lessons on how to get the UI hooked up with Firebase. Good luck.
niiice !
Thanks! This video really help alot :D
You're very welcome.
I have a question for you
is macbook air 2017 is worth it for a programmer.
What are your thoughts :
guard .... else { return }
Vs
guard .... else {
return
}
When guard statements have nothing inside the brackets haha
+Jean-Louis Murphy I prefer the first one since it’s more compact
You just settled a very nagging debate on my end, thank you! hahaha
Thanks a lot for tutorial :) so could you please make a tutorial about MVC on Swift if you not mind :) I really really want to know how to make an app with the clean code :)
Thank you, appreciate
Great tips.
Hi! Which monitor you use?)
How frequently do you make new folders for functions/classes?
Whenever necessary, always avoid polluting your files with code that belongs in a siloed off location.
Hello, I am new here. And what software do u use for editing code?
What do you mean for "editing code"?
You write code for macOS/iOS/etc in the xCode IDE.