| Topic | Presenter | Summary | Duration | Tags | Quiz | Captions |
| ------------------ | ------------- | ----------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---- | -------- |
| Naming Conventions | Chris Reddick | This video documents some common naming convention that Clarity developers should follow. | 17:50 | #DevTrainings, #ClarityTraining, #NamingConventions, #DeveloperTrainingVideos, #NamingConventions, #BestPractices, | N/A | |00:00:00.400 --> 00:00:06.000 - Alright, an if you guys want if it works I can go over the. 00:00:06.620 --> 00:00:13.297 - Coding conventions 1st and see you're welcome to also dig in 00:00:13.297 --> 00:00:16.939 - on this on the JavaScript side. 00:00:17.570 --> 00:00:21.054 - If he wants while I'm going over this, I've got a pretty generic 00:00:21.054 --> 00:00:24.538 - and I think it's still helpful. As I say that not to be 00:00:24.538 --> 00:00:27.486 - discouraging of paying attention to it. 'cause I think it's a 00:00:27.486 --> 00:00:31.562 - good reminder. But pretty kind of generic Microsoft kind of 00:00:31.562 --> 00:00:35.690 - coding conventions page that we can look at together an. I do 00:00:35.690 --> 00:00:39.818 - really think it is helpful. It even talks about some of the 00:00:39.818 --> 00:00:42.914 - stream string interpolation that we talked about last week. 00:00:43.590 --> 00:00:47.594 - And it has a pretty strong opinion that it kind of shows on 00:00:47.594 --> 00:00:51.598 - that. So anyway, if you want to pull up the JavaScript stuff in 00:00:51.598 --> 00:00:55.294 - the background as well, I think that would be pretty cool an 00:00:55.294 --> 00:00:58.682 - anyway, can you guys see my screen? It looks like again. 00:00:59.880 --> 00:01:04.417 - And basically let me put this link in the channel as well so 00:01:04.417 --> 00:01:05.813 - you guys have this. 00:01:06.490 --> 00:01:10.662 - So I'd love for you guys to skim through this and I'm again, I'm 00:01:10.662 --> 00:01:14.834 - putting the link in the channel. So now you should see it. So any 00:01:14.834 --> 00:01:18.708 - who if you'll take a look at the Lincoln kind of scroll through 00:01:18.708 --> 00:01:22.582 - and kind of point out anything that you think is helpful or you 00:01:22.582 --> 00:01:25.860 - think is useful information in general. I just want to point 00:01:25.860 --> 00:01:29.436 - out overall as a resource. This is an awesome resource. If you 00:01:29.436 --> 00:01:33.906 - see this tree view on the left, it is a great way to just kind 00:01:33.906 --> 00:01:37.184 - of poke around and remind yourself of some of these kinds 00:01:37.184 --> 00:01:40.462 - of key vocabulary pieces and get some examples and see actual. 00:01:40.520 --> 00:01:45.448 - Use cases etc. So I I find this to be a really helpful resource. 00:01:45.448 --> 00:01:50.376 - I know a lot of folks that really do as well, but first of 00:01:50.376 --> 00:01:52.136 - all just going in naming 00:01:52.136 --> 00:01:55.894 - conventions. Think this is something that you know most of 00:01:55.894 --> 00:02:00.030 - the team is pretty familiar with. Certainly, feel free if you 00:02:00.030 --> 00:02:04.166 - guys have any comments in general, but just kind of goes 00:02:04.166 --> 00:02:06.798 - over vocabulary or just capitalization for naming 00:02:06.798 --> 00:02:10.576 - conventions. Ann and I think generally the idea is that 00:02:10.576 --> 00:02:13.920 - you're going to be pretty self describing. Whenever you name a 00:02:13.920 --> 00:02:16.960 - variable, I think everybody is pretty familiar with that. Try 00:02:16.960 --> 00:02:20.912 - not to. If you can, try not to abbreviate too much. It's tends 00:02:20.912 --> 00:02:25.168 - to be better to be more clear as opposed to not, but you don't 00:02:25.168 --> 00:02:26.384 - want to have like. 00:02:27.180 --> 00:02:31.558 - Like 12 sentence is in one vocabulary name or one variable 00:02:31.558 --> 00:02:36.990 - name. Um? I think sometimes you can get a little carried away 00:02:36.990 --> 00:02:40.734 - with parentheses, but a lot of times it's more helpful than it 00:02:40.734 --> 00:02:44.478 - is not, especially if you're kind of having to look at order 00:02:44.478 --> 00:02:46.662 - of operations versus just putting parentheses around 00:02:46.662 --> 00:02:50.094 - things. Then just use the parentheses, like if you have to 00:02:50.094 --> 00:02:52.902 - think about like what's the order of operations, please. 00:02:53.570 --> 00:02:57.296 - For the love of God, put parentheses in there. 00:02:57.300 --> 00:03:01.920 - The main thing is we want to try to get our standards to match. 00:03:01.920 --> 00:03:04.890 - Kind of the some significant extent. The lowest common 00:03:04.890 --> 00:03:08.190 - denominator. Just because we're trying to write this for a 00:03:08.190 --> 00:03:11.820 - business. We're not trying to write it for academics. You know 00:03:11.820 --> 00:03:15.450 - who all are perfect at this. There are people at different 00:03:15.450 --> 00:03:17.100 - levels that need to interact 00:03:17.100 --> 00:03:21.658 - with the code. And then of course comments and. 00:03:22.320 --> 00:03:26.701 - I think in general this is what I was talking about. The string 00:03:26.701 --> 00:03:29.734 - interpret interpolation. So you can see they're basically saying 00:03:29.734 --> 00:03:33.104 - you use string interpolation. If it's something pretty simple and 00:03:33.104 --> 00:03:38.159 - minor, but if it's going to be looped an if it's going to be a 00:03:38.159 --> 00:03:42.877 - large amount of data. And this is kind of what we came to last 00:03:42.877 --> 00:03:47.258 - week as well. That's when you're going to use a string builder so 00:03:47.258 --> 00:03:50.965 - you can see the implementation of that right here. So that's 00:03:50.965 --> 00:03:56.506 - pretty simple. And then it also this is interesting. I think 00:03:56.506 --> 00:04:00.682 - everyones pretty familiar with this in general, but if 00:04:00.682 --> 00:04:04.394 - something isn't clear like you're actually calling a 00:04:04.394 --> 00:04:08.316 - method. It's not necessarily clear with the data type return 00:04:08.316 --> 00:04:11.556 - type is. That's a good scenario where you would actually 00:04:11.556 --> 00:04:14.148 - explicitly define the type instead of Justice. Using 00:04:14.148 --> 00:04:18.360 - implicit with of our. Well, so like the one word that was the 00:04:18.360 --> 00:04:21.924 - result so far, and using the explicit type. That also assumes 00:04:21.924 --> 00:04:26.460 - that you don't have an IDE where you can just hover over var for 00:04:26.460 --> 00:04:30.348 - real quick and see what the variable type is. Yeah, I agree. 00:04:30.348 --> 00:04:34.560 - I mean, I think in some cases like we're not going to go 00:04:34.560 --> 00:04:38.778 - through and be. You know police about this. This is Microsoft's 00:04:38.778 --> 00:04:40.382 - an opinion on it. 00:04:40.990 --> 00:04:46.156 - I do think that they generally are at least a good, if not a 00:04:46.156 --> 00:04:49.477 - great resource. Maybe not perfect, so like James is 00:04:49.477 --> 00:04:54.381 - saying. Like if if if you are using a lot of method calls and 00:04:54.381 --> 00:04:58.065 - you're assigning, you know a lot of variables and this is just 00:04:58.065 --> 00:05:01.749 - pedantic than I would say user judgment OK. And then I think 00:05:01.749 --> 00:05:06.047 - one of the other things they talk about is just try not to be 00:05:06.047 --> 00:05:08.810 - confusing is basically what they're saying here. You know, 00:05:08.810 --> 00:05:12.801 - name your variables so that they they do make sense to folks and 00:05:12.801 --> 00:05:14.029 - you're trying to like. 00:05:14.750 --> 00:05:17.930 - I think the biggest thing that you see with this is you're 00:05:17.930 --> 00:05:21.375 - assuming that you're not going to look at this for a year or 00:05:21.375 --> 00:05:25.613 - two. How can you name things so that when you come back to it, 00:05:25.613 --> 00:05:28.625 - or when somebody who's never seen it before it looks at it, 00:05:28.625 --> 00:05:31.888 - they can pick it up and there isn't a lot of what's called 00:05:31.888 --> 00:05:35.564 - code smell. Where literally things aren't logical or they 00:05:35.564 --> 00:05:39.326 - don't make sense, or there are more complicated than they have 00:05:39.326 --> 00:05:43.350 - to be. I said that I let it part would be fine. 00:05:45.110 --> 00:05:48.190 - Yeah, so that's so different folks have different opinions on 00:05:48.190 --> 00:05:52.502 - this and that's the thing that I also want to point out with this 00:05:52.502 --> 00:05:56.506 - is, you know, please for some of the junior team members or other 00:05:56.506 --> 00:06:00.510 - senior team members don't just like send a link to one part of 00:06:00.510 --> 00:06:04.206 - this and be like your code is horrible. I rewrote it all 00:06:04.206 --> 00:06:07.594 - because of this one thing. One of the interesting things about 00:06:07.594 --> 00:06:11.290 - software development is it is kind of, you know, at some level 00:06:11.290 --> 00:06:15.294 - each person has a different way of doing it, and as long as 00:06:15.294 --> 00:06:16.780 - we're generally being. Operating 00:06:16.780 --> 00:06:20.970 - within reason. Within a certain standard and and I don't know if 00:06:20.970 --> 00:06:23.940 - other people have a different opinion, I'd love to hear it. 00:06:24.460 --> 00:06:29.962 - The main thing is that we need to try not to be confusing. If 00:06:29.962 --> 00:06:34.285 - all of us think that's not confusing, then that's fine as 00:06:34.285 --> 00:06:39.394 - long as it's clear that's what we're going for. But I think we 00:06:39.394 --> 00:06:44.503 - all could agree that if it was named like lower case, I and 00:06:44.503 --> 00:06:48.826 - then uppercase INT, that might be so confusing that and it 00:06:48.826 --> 00:06:52.756 - doesn't follow the convention of like actually having full words 00:06:52.756 --> 00:06:56.940 - where possible. So I sometimes whenever I'm actually working on 00:06:56.940 --> 00:06:59.460 - things, I get kind of lazy. 00:07:00.120 --> 00:07:04.320 - I know that no one else probably does that. It's just me, but I 00:07:04.320 --> 00:07:09.366 - might do. He said sarcastically, but I might do this. 00:07:11.410 --> 00:07:14.890 - Which is not great. 00:07:15.060 --> 00:07:18.792 - I'm not saying that anybody's gonna like hurt you over it, but 00:07:18.792 --> 00:07:23.764 - I mean. It doesn't really tell you much an then it can get 00:07:23.764 --> 00:07:27.548 - really confusing if you have a lot of these throughout. It's 00:07:27.548 --> 00:07:32.020 - hard to know what you intended to use it for, and then it's 00:07:32.020 --> 00:07:34.084 - just harder to follow your code 00:07:34.084 --> 00:07:40.940 - so. And then I think we kind of hit on this a little bit. 00:07:43.260 --> 00:07:48.624 - Oh, this is interesting. I'll let you guys read this with me. 00:07:48.624 --> 00:07:53.988 - Kind of need this myself. OK so they're just saying that if 00:07:53.988 --> 00:07:58.458 - you're doing for each that you shouldn't use implicit typing. 00:07:58.458 --> 00:08:04.269 - If you're just doing a four you should. But how come that? I 00:08:04.269 --> 00:08:10.080 - mean, for each if you know it's going to be a jar, right? 00:08:10.110 --> 00:08:14.534 - I don't know the answer to that and I don't see that here. They 00:08:14.534 --> 00:08:18.326 - are saying that var should be an int there. I'm not really 00:08:18.326 --> 00:08:19.274 - understanding what they're 00:08:19.274 --> 00:08:22.980 - implying. Yeah, I think that bar is just an in here. 00:08:25.610 --> 00:08:30.272 - Yeah, I I don't know that I even agree with this either, but I 00:08:30.272 --> 00:08:31.604 - think basically they're saying. 00:08:32.360 --> 00:08:36.070 - Let's see, for example maybe performance thing. I was just 00:08:36.070 --> 00:08:40.893 - curious is all there wouldn't be as far as in when it's compiled. 00:08:40.893 --> 00:08:45.345 - Var is always replaced with the actual type, so it doesn't mean 00:08:45.345 --> 00:08:48.684 - there's no difference to the compiler unless you've written 00:08:48.684 --> 00:08:53.878 - down a type that is not the type that it would have been ferd. 00:08:55.640 --> 00:08:59.800 - I would love for someone to go look this up 'cause I'm sure 00:08:59.800 --> 00:09:01.080 - there's some good stackoverflow 00:09:01.080 --> 00:09:04.868 - on this and. Uh, there's probably some pretty good. 00:09:05.370 --> 00:09:07.470 - Detail around it. 00:09:08.680 --> 00:09:15.284 - And this they might be kind of trying to speak to this piece 00:09:15.284 --> 00:09:18.332 - with the note the giant note 00:09:18.332 --> 00:09:23.326 - that's underneath. Where they're basically just saying it's easy 00:09:23.326 --> 00:09:25.598 - to unintentionally switch your 00:09:25.598 --> 00:09:29.020 - type. Of an Iterable 00:09:29.020 --> 00:09:33.972 - Collection unknowingly. And I can change the. Yeah, I think 00:09:33.972 --> 00:09:37.680 - what they're saying there is you might change the type of laugh 00:09:37.680 --> 00:09:42.006 - too. You know, from a string to like a list of string and then 00:09:42.006 --> 00:09:46.023 - you might then the for each loop would still run, but it would 00:09:46.023 --> 00:09:50.550 - then start generating. Different results logic here yeah. 00:09:51.510 --> 00:09:54.786 - Yeah, so will someone take this offline and go dig into it for 00:09:54.786 --> 00:09:58.062 - next week and be our hero and tell us why this is. According 00:09:58.062 --> 00:10:00.078 - to the MSDN site why this is a 00:10:00.078 --> 00:10:04.990 - bad idea? Kind of sounds like Brendan said me makes sense, I 00:10:04.990 --> 00:10:09.686 - mean. I guess it's trying to future proof your stuff 00:10:09.686 --> 00:10:13.650 - possibly. And maybe you guys could post to whoever does this 00:10:13.650 --> 00:10:15.198 - can post to stackoverflow on it. 00:10:15.840 --> 00:10:21.164 - So are you volunteering Brendan? Is that what I heard Jesse? 00:10:21.170 --> 00:10:23.840 - No, as tribute. 00:10:24.390 --> 00:10:31.446 - Yeah I can. I just think this is such a simple idea 00:10:31.446 --> 00:10:33.210 - that's very simple. 00:10:33.930 --> 00:10:37.146 - It might not be worth the effort. Well, I would love to 00:10:37.146 --> 00:10:40.630 - find out about it. If no one else thinks that it's a big 00:10:40.630 --> 00:10:43.766 - deal, no worries. OK, use the 00:10:43.766 --> 00:10:48.430 - concise syntax. Yeah, I think again, I'll just kind of let you 00:10:48.430 --> 00:10:52.317 - guys kind of read this. I think most of the back end team 00:10:52.317 --> 00:10:53.812 - members kind of know these 00:10:53.812 --> 00:10:55.740 - things but. Um? 00:10:56.610 --> 00:10:58.470 - Basically just trying to get. 00:10:59.320 --> 00:11:05.238 - Get our declaration to happen all in one line instead of 00:11:05.238 --> 00:11:07.390 - explicitly assigning the values. 00:11:08.830 --> 00:11:10.445 - I'm not curious over into 00:11:10.445 --> 00:11:14.640 - JavaScript as well. And then OK try catch. I think we're all 00:11:14.640 --> 00:11:15.840 - pretty familiar with this. 00:11:16.560 --> 00:11:21.070 - Nothing Super special there. I don't think that we use. 00:11:22.550 --> 00:11:28.721 - This very much they're basically saying, You know, don't do a 00:11:28.721 --> 00:11:34.892 - try. Finally, actually go and use it using, so don't make 00:11:34.892 --> 00:11:37.136 - resources available. That then 00:11:37.136 --> 00:11:42.826 - wouldn't get. Disposed of on their own use using's wherever 00:11:42.826 --> 00:11:47.296 - you can to automatically dispose of those resources. The funny 00:11:47.296 --> 00:11:51.319 - thing is those two blocks of code aren't compareable. 00:11:52.010 --> 00:11:56.186 - Are using black isn't a try catch. It's not going to handle 00:11:56.186 --> 00:11:57.926 - an exception if it occurs. 00:11:58.560 --> 00:11:59.778 - So that's misleading. 00:12:00.400 --> 00:12:03.975 - Yeah, it is the main idea though, is that they're just 00:12:03.975 --> 00:12:07.225 - saying like here, they're disposing of it no matter what. 00:12:07.225 --> 00:12:08.525 - Once it gets done. 00:12:09.340 --> 00:12:13.223 - And then here there not. They don't have to explicitly dispose 00:12:13.223 --> 00:12:15.694 - of it. It happens with the using 00:12:15.694 --> 00:12:19.170 - statement. And then 00:12:19.170 --> 00:12:25.435 - basically the. Just the and and or operators. The I don't 00:12:25.435 --> 00:12:29.080 - know if anyone ever really consistently that. I've seen 00:12:29.080 --> 00:12:33.940 - uses a single one of these. It's always using both. Unless I'm 00:12:33.940 --> 00:12:38.800 - mistaken, you guys think of a time where you wouldn't use. The 00:12:38.800 --> 00:12:43.660 - only time you would use a single ampersand or simple a single 00:12:43.660 --> 00:12:47.710 - pipe would be if you're doing bitwise operations, which we 00:12:47.710 --> 00:12:49.330 - don't commonly do, yeah. 00:12:50.010 --> 00:12:53.365 - Yeah, there's probably 2 maybe three places in the entire stuff 00:12:53.365 --> 00:12:56.720 - solution that would do that, and it's just for interfacing with 00:12:56.720 --> 00:13:00.747 - like. Like system resource level stuff. That's like a library 00:13:00.747 --> 00:13:05.336 - that we don't control and the only way to mess with it like 00:13:05.336 --> 00:13:09.572 - like like whether a whether a certain flag operator enum is in 00:13:09.572 --> 00:13:12.749 - place while interfacing with something that has to control 00:13:12.749 --> 00:13:15.573 - with the system resource of memory or something. 00:13:16.300 --> 00:13:20.596 - Got it, yeah? And then this is just going into using the 00:13:20.596 --> 00:13:23.818 - concise form of instantiation. An basically object creation. So 00:13:23.818 --> 00:13:28.472 - if you're going to do something up and then new new an object 00:13:28.472 --> 00:13:33.126 - up, you would give it. Ideally give it as values in this form 00:13:33.126 --> 00:13:37.780 - and you can make this. You can put this on another line and 00:13:37.780 --> 00:13:41.718 - still assign everything nice and neatly on each one of these 00:13:41.718 --> 00:13:45.656 - variables having its own line. That's typically how we do it 00:13:45.656 --> 00:13:50.448 - instead. And just in general, whereas this is literally, you 00:13:50.448 --> 00:13:55.322 - know. Get taking the object name in each of the properties and 00:13:55.322 --> 00:13:57.254 - assigning them manually 1 by 1. 00:13:59.070 --> 00:14:00.638 - So don't do this. 00:14:01.220 --> 00:14:07.600 - Do you do this? Good wood, same idea, just trying. There's 00:14:07.600 --> 00:14:09.340 - talking about not. 00:14:10.290 --> 00:14:14.830 - Not doing things that you have to try to manually 00:14:14.830 --> 00:14:16.192 - clean up later. 00:14:17.920 --> 00:14:23.392 - And this is. This is actually pretty helpful on the link side 00:14:23.392 --> 00:14:26.478 - of things. Again, I don't necessarily know that I would 00:14:26.478 --> 00:14:29.730 - say I agree with all of it like they're talking about using 00:14:29.730 --> 00:14:35.676 - aliases. But I think I'd be interested to hear what some of 00:14:35.676 --> 00:14:38.006 - the team thinks on this. 00:14:39.430 --> 00:14:45.210 - So where there might be confusion or just where it's 00:14:45.210 --> 00:14:49.834 - unclear there reference recommending that use aliases to 00:14:49.834 --> 00:14:51.568 - define things clearly. 00:14:52.100 --> 00:14:57.677 - I can't think of any places in Ceph where we write out linq 00:14:57.677 --> 00:15:02.396 - expressions in the full format like that as opposed to using. 00:15:03.180 --> 00:15:07.572 - There's there are three or four like that, and it's because of 00:15:07.572 --> 00:15:11.964 - the way that the join has to be done between certain things, 00:15:11.964 --> 00:15:15.258 - performance issues or something that the method chain can't 00:15:15.258 --> 00:15:19.650 - support. But it's yeah, it's just it's a couple of places and 00:15:19.650 --> 00:15:24.774 - that's it. I was going to ask why, why that we don't do that 00:15:24.774 --> 00:15:28.800 - everywhere else? 'cause I suggest it. To me it looks kind 00:15:28.800 --> 00:15:33.192 - of neat. It's all SQL and stuff is just load too much. 00:15:33.240 --> 00:15:37.552 - It is a lot of stuff that is less explicit it. Yes, it does 00:15:37.552 --> 00:15:41.248 - look more like more like SQL, but it's not written the same 00:15:41.248 --> 00:15:44.636 - way that sequel actually is, and it's hard to physically visually 00:15:44.636 --> 00:15:47.716 - trace what step is happening after another step part because 00:15:47.716 --> 00:15:51.720 - of the way that you have to write that stuff down versus the 00:15:51.720 --> 00:15:55.416 - method chain where it has to happen in the order that the 00:15:55.416 --> 00:15:59.112 - chain is executing. Yeah, it's a lot less readable in my opinion. 00:15:59.720 --> 00:16:01.980 - That's Fair, that's cool. 00:16:03.370 --> 00:16:06.685 - Yeah, let's see if we can get a visual on this or not, 00:16:06.685 --> 00:16:10.925 - hopefully. Just for anyone who wasn't clear on what they're 00:16:10.925 --> 00:16:15.065 - talking about. Yeah, right at the top there it had the dot 00:16:15.065 --> 00:16:18.860 - right here, yeah. And then you give it a little Lambda 00:16:18.860 --> 00:16:19.550 - function inside. 00:16:21.400 --> 00:16:24.183 - Yeah, so this is a method version, whereas this is just 00:16:24.183 --> 00:16:27.725 - kind of the query syntax so you can see the query syntax is just 00:16:27.725 --> 00:16:29.243 - like looks like a SQL statement. 00:16:30.710 --> 00:16:33.780 - Yeah, whereas the method syntax is like this and you 00:16:33.780 --> 00:16:36.850 - can change the method syntax so you can just keep 00:16:36.850 --> 00:16:40.227 - infinitely and in some areas of our code we probably have 00:16:40.227 --> 00:16:40.534 - like. 00:16:41.700 --> 00:16:44.408 - 1020 thirty of these. 00:16:45.280 --> 00:16:48.712 - Is 'cause there's no better way to do it right? But that's 00:16:48.712 --> 00:16:52.144 - method syntax and then this is query syntax and we also like 00:16:52.144 --> 00:16:55.862 - because of the filter buys the we and a lot of those queries. 00:16:55.862 --> 00:16:59.008 - We changed the filter buys instead of the wares so that 00:16:59.008 --> 00:17:02.154 - they are reusable. Where's that are common stuff so people don't 00:17:02.154 --> 00:17:05.872 - have to make a mistake of like how they wrote the where, the 00:17:05.872 --> 00:17:09.018 - Where is already written into the filter by correctly and you 00:17:09.018 --> 00:17:10.734 - should use the filter by Jane. 00:17:11.680 --> 00:17:16.650 - Yeah, so we made our own methods that can be chained in here that 00:17:16.650 --> 00:17:20.555 - essentially just our our methods that you call an. Then they 00:17:20.555 --> 00:17:24.105 - construct this little where based on the filter type filter 00:17:24.105 --> 00:17:27.655 - by type. Then it's consistent across the entire application so 00:17:27.655 --> 00:17:32.270 - you don't have to try to build this logic every time you just 00:17:32.270 --> 00:17:34.755 - say filter by blah and then it 00:17:34.755 --> 00:17:39.394 - just works. So it's a big deal for consistency if we want to 00:17:39.394 --> 00:17:41.242 - have a check, we want to have 00:17:41.242 --> 00:17:43.832 - the same. Syntax for that, check 00:17:43.832 --> 00:17:48.643 - everywhere. Agreed. There's a method to the madness of 00:17:48.643 --> 00:17:49.630 - using the methods.