1 00:00:00,780 --> 00:00:02,220 My name is Ashish Mahabal and 2 00:00:02,220 --> 00:00:05,842 we'll be continuing with the best programming practices module. 3 00:00:05,842 --> 00:00:09,150 So one things that we'll see this time is what it 4 00:00:09,150 --> 00:00:11,530 is that one should do before the project starts. 5 00:00:11,530 --> 00:00:14,440 Of course during the project you'll be doing lots and lots of things, but 6 00:00:14,440 --> 00:00:18,590 equally important are various things you must do before the project starts, 7 00:00:18,590 --> 00:00:21,800 and that includes digging for requirements. 8 00:00:21,800 --> 00:00:26,900 Be thorough about trying to find out what it is that will required in the project. 9 00:00:26,900 --> 00:00:30,630 Then document those requirements as much as possible. 10 00:00:30,630 --> 00:00:31,790 Make a use case diagram. 11 00:00:31,790 --> 00:00:34,110 Who is it who will be using that project? 12 00:00:34,110 --> 00:00:35,700 Who will be running it? 13 00:00:35,700 --> 00:00:39,740 And what are the conditions in which the project will be run, 14 00:00:39,740 --> 00:00:41,250 in which the program will be run? 15 00:00:41,250 --> 00:00:45,078 Because once you know that, once you have those diagrams, and it will give you 16 00:00:45,078 --> 00:00:49,600 a better idea about as to how to go about making that particular program or project. 17 00:00:49,600 --> 00:00:51,380 Similarly, maintain a glossary. 18 00:00:51,380 --> 00:00:56,430 Many times people who write the programs do not have enough domain knowledge or 19 00:00:56,430 --> 00:00:58,760 the domain in which the programs are being written. 20 00:00:58,760 --> 00:01:01,740 So it is very important to get to know which are the terms in 21 00:01:01,740 --> 00:01:05,500 the domain that you'll be needing, which are the computing terms you'll be needing. 22 00:01:05,500 --> 00:01:06,830 And once you have a glossary of that, 23 00:01:06,830 --> 00:01:10,750 how they're connected, how they work with each other, that is important to know. 24 00:01:12,290 --> 00:01:16,550 Similarly, I cannot or emphasize the importance of documentation. 25 00:01:16,550 --> 00:01:20,080 Do as much documentation as possible at every stage. 26 00:01:20,080 --> 00:01:24,275 This not only includes comments that go into the programs, but also meta 27 00:01:24,275 --> 00:01:29,660 comments that can go into configuration file and external readme files, et cetera. 28 00:01:29,660 --> 00:01:32,200 So document, document, document as much as possible. 29 00:01:33,820 --> 00:01:39,220 One tradeoff one has between maintenance and development is that clearly, 30 00:01:39,220 --> 00:01:41,280 if you do quick development or 31 00:01:41,280 --> 00:01:45,610 if the development seems easy, very likely the program will not be maintainable. 32 00:01:45,610 --> 00:01:48,140 Maybe some short cuts have been used, et cetera. 33 00:01:48,140 --> 00:01:52,180 So be thorough in your development process. 34 00:01:52,180 --> 00:01:56,270 As a result of that you will find that the maintenance becomes that much easier. 35 00:01:56,270 --> 00:01:59,220 You, yourself will very likely be maintaining the programs or 36 00:01:59,220 --> 00:02:00,670 one of your teammates will be. 37 00:02:00,670 --> 00:02:05,250 But in either case, if you want to save everyone a grief, some grief, 38 00:02:05,250 --> 00:02:08,556 then maybe the development process should be thorough, deliberate and 39 00:02:08,556 --> 00:02:11,190 in appropriate short steps. 40 00:02:11,190 --> 00:02:15,790 Because the projects live much more longer than one expects them initially. 41 00:02:15,790 --> 00:02:20,230 And for that, what you may have to do is to adopt a more complex language. 42 00:02:20,230 --> 00:02:23,860 By complex language, I do not mean complicated language, but simply complex 43 00:02:23,860 --> 00:02:29,460 enough that incorporates all the structure that is needed in the specific project. 44 00:02:29,460 --> 00:02:33,026 And that will automatically make it readable, it'll show the relationships 45 00:02:33,026 --> 00:02:36,500 between different parts of the program and you'll be better off. 46 00:02:36,500 --> 00:02:40,760 So again, what should be involved when you start a project and 47 00:02:40,760 --> 00:02:45,300 take various steps in order to complete it, is check the requirements of 48 00:02:45,300 --> 00:02:48,220 the specific module, specific part that you are working on. 49 00:02:49,250 --> 00:02:53,870 Go ahead, do a design related to that, implement that design, and 50 00:02:53,870 --> 00:02:57,810 then integrate that design into what has existed until then. 51 00:02:57,810 --> 00:03:01,020 And of course one critical step at that point is validation. 52 00:03:01,020 --> 00:03:03,900 You should validate the work that has been done. 53 00:03:03,900 --> 00:03:10,750 This also applies is to when you take libraries or programs written by others. 54 00:03:10,750 --> 00:03:15,390 So, when you are basing your work on that already done by others, 55 00:03:15,390 --> 00:03:17,910 you should validate various items within that. 56 00:03:17,910 --> 00:03:20,450 For instance, even things like numbers and 57 00:03:20,450 --> 00:03:23,230 characters, what is being called a number, is it really a number? 58 00:03:23,230 --> 00:03:26,130 What happens if you give a character's input or vice versa? 59 00:03:26,130 --> 00:03:27,560 If something that's being called a character, 60 00:03:27,560 --> 00:03:30,330 what happens if you give a number as an input? 61 00:03:30,330 --> 00:03:33,650 Similarly, make sure that all the constraints are correctly met. 62 00:03:33,650 --> 00:03:37,850 Here you see a diagram of the sky where a particular parameter called 63 00:03:37,850 --> 00:03:40,740 declination goes from minus 90 to 90. 64 00:03:40,740 --> 00:03:42,960 And if it appears in one of your programs and 65 00:03:42,960 --> 00:03:46,680 someone goes in as input number 100, what is it that's going to happen? 66 00:03:47,680 --> 00:03:49,200 Then check consistency. 67 00:03:49,200 --> 00:03:53,190 Are you seeing contradictory things about the same point at different places in 68 00:03:53,190 --> 00:03:53,960 the program? 69 00:03:53,960 --> 00:03:57,180 If that is so, then better you have to resolve that. 70 00:03:57,180 --> 00:03:59,970 So, whenever you take someone elses programs make sure you do that. 71 00:04:01,200 --> 00:04:03,860 But then you should not trust yourself either. 72 00:04:03,860 --> 00:04:06,280 All of those above things you should do to your own program. 73 00:04:06,280 --> 00:04:09,080 Whenever you have written a piece of code, make sure you 74 00:04:09,080 --> 00:04:13,720 validate that with consistency, for consistency, and for constraints as well. 75 00:04:15,460 --> 00:04:16,690 But despite all this, 76 00:04:16,690 --> 00:04:20,510 what is going to happen is there will be cases when things will go wrong. 77 00:04:20,510 --> 00:04:23,030 Some parameters will not be correctly input. 78 00:04:23,030 --> 00:04:26,440 And at, on such an occasion what you should make sure is that 79 00:04:26,440 --> 00:04:29,390 your programs crash early rather than late. 80 00:04:29,390 --> 00:04:33,870 For instance, if a particular subroutine needs four arguments and 81 00:04:33,870 --> 00:04:35,770 you go through a lot of competition and 82 00:04:35,770 --> 00:04:39,640 then try to validate whether the fourth argument was in the correct form. 83 00:04:39,640 --> 00:04:43,400 And you find that actually you did not like a little bit over there. 84 00:04:43,400 --> 00:04:46,080 Then crashing at that point is not a good idea, 85 00:04:46,080 --> 00:04:49,650 because already you have spent some time doing computation that 86 00:04:49,650 --> 00:04:54,730 involves a foot on the computer time spent during computation. 87 00:04:54,730 --> 00:04:57,420 So it may have been much better if you have looked for 88 00:04:57,420 --> 00:05:01,200 all the arguments that are being given, whether all of them are consistent, and 89 00:05:01,200 --> 00:05:03,480 they follow the constraints that you wanted them to be. 90 00:05:04,620 --> 00:05:08,360 Then if you have to crash, if you are to come out of the program, 91 00:05:08,360 --> 00:05:14,170 you better should do it in a way that does really trash other than crash. 92 00:05:14,170 --> 00:05:17,580 By trash, what I mean here is leaving a lot of messages which either do 93 00:05:17,580 --> 00:05:20,760 not make sense, or do not provide important or 94 00:05:20,760 --> 00:05:24,180 useful information to the person who is trying to run the program. 95 00:05:24,180 --> 00:05:27,400 So perl has a different phase of coming out of a program. 96 00:05:27,400 --> 00:05:31,150 If the die command is used, the program simply dies. 97 00:05:31,150 --> 00:05:32,030 It doesn't do anything else. 98 00:05:32,030 --> 00:05:32,860 It just comes out and 99 00:05:32,860 --> 00:05:37,110 doesn't tell you anything that is reasonably important or useful. 100 00:05:37,110 --> 00:05:40,890 But instead of that, you could use a sub croak which then blames the caller. 101 00:05:40,890 --> 00:05:45,620 It tells you which subroutine called that particular line which caused the problem 102 00:05:46,780 --> 00:05:48,760 to stop, and the program to stall. 103 00:05:48,760 --> 00:05:51,890 Or you could use something like confess, which gives even more details. 104 00:05:51,890 --> 00:05:56,500 It can go into a very fairly long trace, telling you this routine was called here, 105 00:05:56,500 --> 00:06:00,420 that routine was called there, and where is it that the problem really originated. 106 00:06:01,830 --> 00:06:06,260 So related to that is try and catch, where you can say that the program should 107 00:06:06,260 --> 00:06:09,200 attempt to do something, and if it fails to do that, then one 108 00:06:09,200 --> 00:06:13,560 other possibility is that it could possible steps that it could be taking. 109 00:06:13,560 --> 00:06:16,040 And that is where exceptions can be raised. 110 00:06:16,040 --> 00:06:20,020 If an exception has to be raised, you are to ask, why did that situation come about? 111 00:06:21,080 --> 00:06:23,040 Was it a valid input or not? 112 00:06:23,040 --> 00:06:26,670 And then whether you knew such a situation will arise, and 113 00:06:26,670 --> 00:06:28,440 then take appropriate cases. 114 00:06:28,440 --> 00:06:31,510 So let's see a specific example of the try/except here. 115 00:06:31,510 --> 00:06:33,230 You'll see in the screen two parts. 116 00:06:33,230 --> 00:06:37,740 The top part is one way you should be using try/except, and the second part is 117 00:06:37,740 --> 00:06:41,030 where it's too broad, so you should not be using try/except there. 118 00:06:41,030 --> 00:06:44,810 So in the top part you see that we are using a dictionary and 119 00:06:44,810 --> 00:06:46,750 five columns called collection. 120 00:06:46,750 --> 00:06:48,080 It has various keys. 121 00:06:48,080 --> 00:06:51,790 And we are saying take apart low key and find out what its value is. 122 00:06:51,790 --> 00:06:54,880 And we are asking the program to try getting the value of that 123 00:06:54,880 --> 00:06:56,300 key from the dictionary. 124 00:06:56,300 --> 00:06:59,800 And then we say that if it doesn't find that, then it 125 00:06:59,800 --> 00:07:03,280 should return a function called key not found, when this key is an argument. 126 00:07:03,280 --> 00:07:05,790 And if it is successful in getting the value, 127 00:07:05,790 --> 00:07:10,190 it should simple handle that value using another function called handle value. 128 00:07:10,190 --> 00:07:11,700 So, this would go through quite find, 129 00:07:11,700 --> 00:07:14,500 if it doesn't find the key it will tell you that the key was not found. 130 00:07:14,500 --> 00:07:18,590 If it was found, then it will do an appropriate thing with the value. 131 00:07:18,590 --> 00:07:19,480 But on the other hand, 132 00:07:19,480 --> 00:07:23,980 you can try to make the try/except too broad, as is shown in the second case. 133 00:07:23,980 --> 00:07:28,335 Where you are combining the top two things by saying a return handle value 134 00:07:28,335 --> 00:07:33,440 off the value that is returned by the collection for that particular key. 135 00:07:33,440 --> 00:07:36,600 Clearly, if it works, it works and you get the correct answer, but 136 00:07:36,600 --> 00:07:41,210 if it does not work, then your exception says, a key not found here. 137 00:07:41,210 --> 00:07:44,740 Well, that may be part of the problem, but it is also possible that 138 00:07:44,740 --> 00:07:48,720 the key self was found and error was in the handle value function. 139 00:07:48,720 --> 00:07:51,860 And that is not clear at all from the exception that is being indicated here. 140 00:07:51,860 --> 00:07:56,395 So you have to be careful that you do not have too broad a case of try/accept. 141 00:07:58,630 --> 00:08:03,210 Then forget about finding or eliminating bugs and so on. 142 00:08:03,210 --> 00:08:07,440 You should try not, not to optimize the code, but try to benchmark it. 143 00:08:07,440 --> 00:08:11,860 Let us try to find out where more time is being spent. 144 00:08:11,860 --> 00:08:14,850 What is a better way of using a particular structure? 145 00:08:14,850 --> 00:08:18,050 With the optimizing structure, you can measure them rather than optimizing them. 146 00:08:18,050 --> 00:08:22,400 Where, you find out what is the size of each element of the structure. 147 00:08:22,400 --> 00:08:26,040 And if you're going to have a very big list involving that structure, 148 00:08:26,040 --> 00:08:27,410 how many bytes it's going to take. 149 00:08:27,410 --> 00:08:29,290 And if there is that appropriate form, 150 00:08:30,420 --> 00:08:35,010 then an important thing to do is to cache data when you can. 151 00:08:35,010 --> 00:08:38,010 And this is very important especially when, when you use this, 152 00:08:38,010 --> 00:08:42,850 either recursive functions or list which involved a large number of competitions. 153 00:08:42,850 --> 00:08:46,750 And possibly, some of the competitions are going to be called in again and 154 00:08:46,750 --> 00:08:51,910 again, either within the same competition or by different users in the same program. 155 00:08:52,940 --> 00:08:55,600 So, we'll see an example of that next. 156 00:08:55,600 --> 00:08:59,390 The other thing to do is also benchmarking various strategies for 157 00:08:59,390 --> 00:09:02,800 caching, because even for caching there can be various algorithms. 158 00:09:02,800 --> 00:09:07,490 And for your particular situation, one algorithm may be better than another one. 159 00:09:07,490 --> 00:09:11,070 So, it's a good idea to look at different ones there. 160 00:09:11,070 --> 00:09:14,030 The same thing about optimization goes for applications. 161 00:09:14,030 --> 00:09:17,040 You don't have to try to optimize an entire application, but 162 00:09:17,040 --> 00:09:18,320 you should provide it. 163 00:09:18,320 --> 00:09:22,220 That is, see which part of the program takes up most of the time, 164 00:09:22,220 --> 00:09:25,830 takes up most of the resources and try to reduce that. 165 00:09:25,830 --> 00:09:30,760 That way you'll comparing apples to apples rather than trying to say oh this, 166 00:09:30,760 --> 00:09:32,850 the length of the subroutine looks longer and 167 00:09:32,850 --> 00:09:36,710 that is why maybe I should try reuse the, the number of lines whether than 168 00:09:36,710 --> 00:09:38,690 the time that is being spent on that particular one. 169 00:09:40,150 --> 00:09:43,030 So, here is the example of memorization. 170 00:09:43,030 --> 00:09:47,290 It's a simple program in some simple subroutine, a fact, a factorial. 171 00:09:47,290 --> 00:09:50,830 And a factorial of a positive integer is of course multiplication of 172 00:09:50,830 --> 00:09:53,210 that number with all smaller positive integers. 173 00:09:53,210 --> 00:09:58,300 So, factorial of 4, as you know is 4 times 3 times 2 times 1, which is 24. 174 00:09:58,300 --> 00:10:02,550 Or factorial 5 is 5 times the factorial of 4, 120. 175 00:10:02,550 --> 00:10:03,830 So here, what's being done, 176 00:10:03,830 --> 00:10:07,350 is that we start with an empty dictionary, Factorial_memo. 177 00:10:07,350 --> 00:10:09,240 It doesn't have anything to start with. 178 00:10:09,240 --> 00:10:12,100 And then when the first factorial call comes as is shown in 179 00:10:12,100 --> 00:10:15,750 the last line of this program, call factorial(10), 180 00:10:15,750 --> 00:10:18,810 it'll find that factorial(10) is missing in the dictionary. 181 00:10:18,810 --> 00:10:23,180 So it'll try to calculate factorial 10, for which it needs to calculate factorial 182 00:10:23,180 --> 00:10:26,430 nine, and then factorial eight, and factorial seven, and so on. 183 00:10:26,430 --> 00:10:29,330 But the moment any of those is now calculated, 184 00:10:29,330 --> 00:10:32,040 that gets put in that particular dictionary. 185 00:10:32,040 --> 00:10:35,870 So, whenever that call comes again, you'll already have an automatic answer, and 186 00:10:35,870 --> 00:10:37,260 you can just return that. 187 00:10:37,260 --> 00:10:40,610 And so, after factorial k has been calculated once, 188 00:10:40,610 --> 00:10:42,820 if you call factorial five, the answer will be ready. 189 00:10:42,820 --> 00:10:45,160 You call factorial seven, the answer will be ready. 190 00:10:45,160 --> 00:10:48,350 Only if you call factorial give it a higher number, say factorial 13, 191 00:10:48,350 --> 00:10:49,950 it won't be ready. 192 00:10:49,950 --> 00:10:53,860 But it can then get factorial 13 it will be 13 times 12 times 11 193 00:10:53,860 --> 00:10:58,500 times factorial 10, which already you have and then you'll have all numbers, 194 00:10:58,500 --> 00:11:00,330 all factorials up to 13 in your program. 195 00:11:00,330 --> 00:11:02,390 So this is how you'll go ahead and 196 00:11:02,390 --> 00:11:06,692 do the memorization and will help you caching your earlier results. 197 00:11:06,692 --> 00:11:10,600 Similarly, here's how profiling can be 198 00:11:10,600 --> 00:11:13,980 used of the Python module cProfile can be used. 199 00:11:13,980 --> 00:11:17,520 And here we are seeing how cProfile will work with 200 00:11:17,520 --> 00:11:20,470 a particular regular expression of compiling hello world. 201 00:11:21,970 --> 00:11:27,110 And just that single call to cProfile indicates that there are 238 202 00:11:27,110 --> 00:11:30,075 function calls including 233 primitive calls. 203 00:11:30,075 --> 00:11:31,760 And of course this single statement. 204 00:11:31,760 --> 00:11:34,240 So it practically runs in 0 seconds. 205 00:11:34,240 --> 00:11:39,150 And all the different calls here show that they ran in 0 seconds. 206 00:11:39,150 --> 00:11:40,860 But for a real example of what would happen, 207 00:11:40,860 --> 00:11:45,565 is that it will show you which of the internal statement, either primitive or 208 00:11:45,565 --> 00:11:48,110 one of your function calls is taking more time. 209 00:11:48,110 --> 00:11:51,640 And then that is where you can try to reduce the amount of time. 210 00:11:51,640 --> 00:11:53,870 So in general, you should try to benchmark things, and 211 00:11:53,870 --> 00:11:56,080 there are utilities available for that. 212 00:11:56,080 --> 00:11:59,927 The Benchmarking game allows you to compare different installations, 213 00:11:59,927 --> 00:12:02,205 different programming languages or all. 214 00:12:02,205 --> 00:12:06,026 But if you go to a specific programming language like Python, you have 215 00:12:06,026 --> 00:12:10,885 routines you have website and there are websites available to just compare radius, 216 00:12:10,885 --> 00:12:14,350 modules within five [INAUDIBLE] definitely take a look at that. 217 00:12:16,410 --> 00:12:19,910 Then let's look at some different aspects of programming. 218 00:12:19,910 --> 00:12:23,250 What are the necessary ingredients of a good program. 219 00:12:23,250 --> 00:12:27,170 A program should be robust, it should be efficient, and it should be maintainable. 220 00:12:27,170 --> 00:12:29,650 So, what does one mean by a program being robust? 221 00:12:29,650 --> 00:12:33,720 That it should be able to handle different cases easily, 222 00:12:33,720 --> 00:12:38,180 like h cases in particular, those can be the most troublesome ones. 223 00:12:38,180 --> 00:12:40,430 Is the first case handled correctly? 224 00:12:40,430 --> 00:12:42,720 Is the, does the list start with zero or one? 225 00:12:42,720 --> 00:12:46,070 And whether that has been handled correctly. 226 00:12:46,070 --> 00:12:49,250 Or is the last case that can come about handled correctly? 227 00:12:49,250 --> 00:12:53,280 Similarly, whether there are appropriate tests for different kinds of errors. 228 00:12:53,280 --> 00:12:57,121 How is the error in handling itself done, are exceptions correctly. 229 00:12:57,121 --> 00:12:59,292 So if you build in all these things properly, 230 00:12:59,292 --> 00:13:01,760 then you're going to have fairly robust program. 231 00:13:03,790 --> 00:13:07,410 And one can check for all loaded cases in this fashion here. 232 00:13:07,410 --> 00:13:11,000 What we have is a function simply called square, and 233 00:13:11,000 --> 00:13:15,690 it has a single statement which is X times X, where X is the input. 234 00:13:15,690 --> 00:13:18,760 But then we run something called a doctest within 235 00:13:18,760 --> 00:13:21,030 the comments that are given up there. 236 00:13:21,030 --> 00:13:24,390 So, we have radius examples, it can take two as input and 237 00:13:24,390 --> 00:13:25,460 then it should return four. 238 00:13:25,460 --> 00:13:28,310 And you have minus two as input and it should return four. 239 00:13:28,310 --> 00:13:32,690 You can even input a complex number and get an appropriate response from that. 240 00:13:32,690 --> 00:13:36,410 So you should be making sure that if you have a whole load of cases they 241 00:13:36,410 --> 00:13:41,469 are correctly tested, and they in fact give what you want to come out of them. 242 00:13:41,469 --> 00:13:44,760 Similarly, with efficiency of course a chain as we 243 00:13:44,760 --> 00:13:49,230 all know is weakest when you find the weak point and that. 244 00:13:49,230 --> 00:13:52,710 So you should try to ensure that you are working with strengths of 245 00:13:52,710 --> 00:13:55,810 whatever language you are using, whatever model you're using. 246 00:13:55,810 --> 00:13:58,300 Or whatever combination of those you may be using, and 247 00:13:58,300 --> 00:14:00,070 that you should avoid weaknesses. 248 00:14:00,070 --> 00:14:05,620 A specific example can be especially with compatibility, where Python 2.7 and 249 00:14:05,620 --> 00:14:10,440 Python 3, many people have not made a switch from Python 2.7 to Python 3, 250 00:14:10,440 --> 00:14:14,950 because something as fundamental as the print statement has changed. 251 00:14:14,950 --> 00:14:18,640 And obviously, people don't want to go back and change all their print statement. 252 00:14:18,640 --> 00:14:23,250 So this is a case where microcompatility has not been built in, for 253 00:14:23,250 --> 00:14:24,110 whatever reasons. 254 00:14:24,110 --> 00:14:25,510 But one has to be aware of that. 255 00:14:25,510 --> 00:14:27,100 And when one is writing programs, 256 00:14:27,100 --> 00:14:32,045 one has to make sure that the trade offs are taken into consideration correctly. 257 00:14:32,045 --> 00:14:36,630 Then coming to maintainability, just remember that 258 00:14:36,630 --> 00:14:41,480 more time will be spent in maintaining codes then it took to writing them. 259 00:14:41,480 --> 00:14:44,930 And that can be a painful thing if the code is not well written or 260 00:14:44,930 --> 00:14:46,620 if it is not maintainable. 261 00:14:46,620 --> 00:14:50,440 Because when time goes by, you don't understand your own code, 262 00:14:50,440 --> 00:14:53,710 forget about the code that other have written, others have written. 263 00:14:53,710 --> 00:14:56,660 So make sure you have amply commented the code. 264 00:14:57,740 --> 00:15:00,000 Then, in most cases, you, yourself will maintain it. 265 00:15:00,000 --> 00:15:05,950 So help yourself by making your code maintainabled right from the word, go. 266 00:15:05,950 --> 00:15:10,710 And that can be helped by using consistent practices, as we talked earlier, 267 00:15:10,710 --> 00:15:14,490 a little bit about braces and brackets, and spaces, and line lengths and tabs. 268 00:15:14,490 --> 00:15:16,310 And line lengths, and all of those. 269 00:15:16,310 --> 00:15:18,170 So make sure that you have consistent practices. 270 00:15:18,170 --> 00:15:20,230 If you are managing a big team, 271 00:15:20,230 --> 00:15:23,140 make sure that they follow consistent practices as well. 272 00:15:24,900 --> 00:15:29,210 Next time we'll be looking at design by contract and about comments, and 273 00:15:29,210 --> 00:15:30,710 arguments, and some related aspects.