1 00:00:00,660 --> 00:00:03,790 While we're all done with our lists of rules and exceptions, 2 00:00:03,790 --> 00:00:08,210 we have one small thing left to cover, and that's a series of conventions. 3 00:00:08,210 --> 00:00:11,440 We'll treat this video more or less as a grab bag of different things. 4 00:00:12,630 --> 00:00:14,420 First up, Boolean Methods. 5 00:00:14,420 --> 00:00:15,950 Now this one is simple. 6 00:00:15,950 --> 00:00:16,940 As we saw earlier, 7 00:00:16,940 --> 00:00:22,740 with Boolean properties, we want Boolean Methods to read as assertions. 8 00:00:22,740 --> 00:00:25,470 If you understood how to do this with properties, 9 00:00:25,470 --> 00:00:28,640 methods aren't that much different and here's a simple example. 10 00:00:29,720 --> 00:00:35,430 The instance method returns true if a point in consideration is in range, 11 00:00:35,430 --> 00:00:36,140 false if not. 12 00:00:37,340 --> 00:00:42,990 Since this is a Boolean Method, we write it as an assertion isInRange. 13 00:00:42,990 --> 00:00:45,040 Next up are parameters. 14 00:00:45,040 --> 00:00:47,750 We've covered a lot of ground with argument labels, 15 00:00:47,750 --> 00:00:51,580 there's just a few random things in this set of guidelines. 16 00:00:51,580 --> 00:00:56,810 We always want to choose parameter names that serve documentation. 17 00:00:56,810 --> 00:01:00,620 So here parameter name refers to what we've been calling the local 18 00:01:00,620 --> 00:01:01,390 argument name. 19 00:01:02,700 --> 00:01:06,080 Even though this does not show up at the use site, 20 00:01:06,080 --> 00:01:08,620 at the point of definition the choice of name for 21 00:01:08,620 --> 00:01:13,150 the parameter, should clearly document its role in the function. 22 00:01:13,150 --> 00:01:17,270 This is why earlier we chose index over using the letter I. 23 00:01:18,810 --> 00:01:22,170 In swift, parameters can take default values, and 24 00:01:22,170 --> 00:01:25,410 you are encouraged to use this feature where possible 25 00:01:25,410 --> 00:01:28,700 to simplify function signature and make it more readable. 26 00:01:29,880 --> 00:01:34,170 In Objective C, and in other languages, it's common to define method 27 00:01:34,170 --> 00:01:39,200 families where you have one version of a method that takes all your arguments, and 28 00:01:39,200 --> 00:01:41,470 then successively simpler ones, 29 00:01:41,470 --> 00:01:44,710 where each one provides a default value to the next method. 30 00:01:45,860 --> 00:01:50,760 In Swift, default arguments are preferable to the use of method families. 31 00:01:51,960 --> 00:01:56,780 Here we have an example of a method name that provides either empty values or 32 00:01:56,780 --> 00:01:59,310 nil for the arguments past the first one. 33 00:02:00,470 --> 00:02:02,500 This method reads much better and 34 00:02:02,500 --> 00:02:06,260 reduces cognitive burden through the use of default values. 35 00:02:07,260 --> 00:02:09,630 Just remember, if you do use default arguments, 36 00:02:09,630 --> 00:02:13,240 to keep those default arguments at the end of the function signature. 37 00:02:14,740 --> 00:02:19,300 Speaking along the lines of method families, it's okay for free functions 38 00:02:19,300 --> 00:02:24,040 to share the same base name, as long as they do the same thing more or less. 39 00:02:25,210 --> 00:02:29,450 In the case of methods same base names are fine if they operate 40 00:02:29,450 --> 00:02:30,880 within different domains. 41 00:02:32,090 --> 00:02:35,300 Here we have two methods named contain. 42 00:02:35,300 --> 00:02:40,230 One that operates on a Shape type, one that operates on a Collection. 43 00:02:40,230 --> 00:02:45,220 These are two distinct domains and there's not a lot of room for confusion. 44 00:02:45,220 --> 00:02:49,400 However two methods named index on a collection type for 45 00:02:49,400 --> 00:02:51,010 example would be a bad idea. 46 00:02:52,760 --> 00:02:54,990 Okay, with that let's wrap it up. 47 00:02:54,990 --> 00:02:56,810 We've learned a bunch of new guidelines here, so 48 00:02:56,810 --> 00:02:59,120 it's probably best to let it sink in for a while. 49 00:03:00,200 --> 00:03:02,920 As I mentioned at the beginning of this course, 50 00:03:02,920 --> 00:03:05,980 you really don't have to internalize all of this at once. 51 00:03:06,980 --> 00:03:10,060 In fact it's probably best to take a few of the base rules and 52 00:03:10,060 --> 00:03:15,090 spend time using them until you're quite familiar before moving on. 53 00:03:15,090 --> 00:03:19,370 Honestly, I haven't fully implemented all these guidelines yet myself and 54 00:03:19,370 --> 00:03:23,510 often have to come back to this list to understand some exception or another. 55 00:03:24,740 --> 00:03:25,960 Over the next few courses, 56 00:03:25,960 --> 00:03:29,940 we'll try to implement these rules ourselves as we write code. 57 00:03:29,940 --> 00:03:33,110 We won't do it all at once and now that we're familiar with most of 58 00:03:33,110 --> 00:03:35,610 the guidelines, or at least have a reference point, 59 00:03:35,610 --> 00:03:39,480 I won't be explaining every single thing in detail as we write code in the future. 60 00:03:40,560 --> 00:03:44,280 One thing you could do to make this easier is to make a chart more or less, 61 00:03:44,280 --> 00:03:48,760 that covers some of the nuances like the non mutating methods and mutating pairs. 62 00:03:48,760 --> 00:03:52,150 So that it settles in, it gives you time to look over these over and 63 00:03:52,150 --> 00:03:54,970 over again as you write more code. 64 00:03:54,970 --> 00:03:56,780 Okay, see you in the next course.