 So, hello. And since you seem to be kind of sleepy, let's start with something interactive again. Some of you may remember from Spain. The results are simple. You will get three questions about liberal fees code. If you get your answer right, you get one point. And if you somehow happen to get all three questions right, then you will be the perfect, all-knowing liberal fees developer, which you probably won't. So, ready? This is trivial code. I'm just interested if I set up Colvex this way. This is from the liberal fees view code. If I set up the Colvex this way, which of those Colvex will be called? So, I will just go through the questions and we will get the answers afterwards. So, does somebody still need more time? All clear? Oh, come on, say somebody something. Huh? Oh, okay. Sorry, if you didn't, if I haven't finished too late. The second question. This is from Calc. You may not be exactly familiar with the functions, so I will actually show you the prototypes. So, and we have these simple questions. Simple question. Which of the, the specific code is kind of made up. It's based on more complex, real code. But the question is, which of these functions will actually modify the compiler instance? That should be probably simple, so I guess this is enough time. And the last one. True or false? And just so that it's not 50-50, why true or false? That's just one of the problems. It's actually not all the problems there. There are more of them. Does somebody still want more time to think about this? Okay, so, raise your hand. How many of you? Yeah, let's start from the bottom. How many of you think you have zero correct answers? Okay, so, how many of you hope you have one correct answer? Oh, I'm waiting for the two or three. So, two correct answers. Three correct answers. Okay, so, how many of you are you too shy to raise your hand? Raise your hand now. I'm still missing, like, half of the people here. Anyway, so, as some of you may know, I repeatedly keep bitching about the code being unreadable. All of these are actually real examples. I wasted some time on trying to figure out. I also fixed some of them. So, I had a talk in Spain about this. I'm going to have a slightly different one this time because, apparently, this still can use some repeating. So, yeah, I mean, I find the question about if code readability matters, it kind of does, especially when we're looking at some code we don't quite understand and we keep cursing and we spend, like, one day looking at it and so on. Kind of the problem is here that it's not really compulsory, right? If you don't get the syntax right, it just won't compile. The compiler, like, you cannot talk it down, it just won't work. If you get the functionality wrong, it just will crash. I mean, that's not as strict because we have all the bugs about code not being right. But, still, that's, like, sort of required that it works. But, like, you can write messy code and if it gives the right detail, it's sort of optionally. And we don't have the time. But, of course, then it adds up and then we make things worse over time. It's kind of an investment. If you waste your time today making it better than you get the time back later. And, of course, this is something that spreads because we got a lot of code which is poorly written and there is kind of the compelling to be consistent with the code or just sometimes we don't quite understand so we copy and paste it so the stuff propagates and there are quite many examples which are showing kind of poor practice. I even included some examples from the standard library which also could use some improvement here and there. Like, if you have this empty example, I guess we all know that it's a check but let's say it's not STL or you just don't happen to know. How are you supposed to know from just looking at the code? And you are, for example, looking at the code in Garrett which will not give you any hints. Are you supposed to know if it's a check or if you are actually asking the vector to become empty and you are checking if the operation was successful? I would like to talk about various stuff I have run into, why it's bad and how those could be possibly done better. Hopefully some of that will stick in your minds and if you see some code, you will... When writing code, you will do better and if you see old code, hopefully, you will feel like maybe improving the stuff a bit so that the next... Well, somebody will have suffered sooner or later so maybe you will be in the mood, the person to stop the suffering. So, as I said, this stuff is sort of optional and as the complicated stuff about it that it's, at least to some extent, a matter of taste. You can have your personal opinion on the syntax, but if the compiler doesn't agree, then you can have your opinion all you want and it doesn't matter, but style, people have different ideas. So, I don't want to call these rules, but they are not really rules. They are more like recommendations and apply your judgment. And this is some of the things... I don't want to do specific rules because rules just say, do this, but I would like to also say why you should do this stuff, so this is meant to be a bit more high level and some of the rules should be implied by this. So, let's go on some examples. I have some of the... Oh, yeah. This is one of... I was reordering the slides, so I wasn't expecting this one. One of the good reasons why I was okay about code readability is that actually you spent a lot more time reading the code rather than writing it. Kind of when we are writing the code, we are focused on writing it and we are lazy, so we kind of have the tendency to make the easy writer, but since we will end up reading it a lot more, it will come back to bite us. Yeah, I had this example, for example, if you know from base gaze, do matrix, it just calls its element a, b, c, d, e, f, and the next are hardcoded, but if you see code like matrix.e, how many of you know, if I didn't show you how many of you would know, which one is matrix e? Which one of the... Yeah, after counting, right. It's much simpler if you can read that it's scale x. I don't care if... Maybe this is useful for some cases, but most of the time, if I want to use a matrix, in LibreOffice, I want to use it for the usual stuff, I want to scale, rotate, and translate. Ok, so let's see how well you actually scored, so please don't be shy, raise your hand for true. You have 50-50 chance. So true? No one. Ok, two, three, true? Ok, so the next is false. Can somebody explain why it's false? Well, it doesn't matter because you're wrong, it's true. Yeah, that's kind of the point of the question. There are two questions. So one of the roles I would like to have is that, ideally, you should be able to read the code and just get what it does just for me reading it. So everybody probably look at it as, if R1 is inside R2, but it's actually not what the function does, you are asking R1 if R2 is inside of it. So it actually does the opposite of what it does. That's one of the three visuals there. This doesn't exist anymore, I've already fixed it, the function is not called contains. If R1 contains R2, now it's obvious that it's, well, actually it's not obvious because there is other problem. So if you have the number, what do the numbers actually mean? You have four numbers and there are many ways to specify the rectangle. Like the second one, is it 20 pixels wide? Is it maybe 10 pixels wide, even? So this is actually, it's coordinated, it's not with hate, it's one point, second point. Why? Actually, it's true because the second one is inside the first one because it's coordinated, it's not with. Again, this can be easily improved. You can, for example, remove the first constructor and just force this one. If you explicitly have to specify the point and the size, then it's obvious. Or we can do, for example, as Skiya does, it doesn't allow such constructors to call static functions, which use the name. Now, you can see, obviously, what the four numbers mean. And this can be applied to more various constructors, which have, like, a bunch of numbers or a bunch of arguments. So, yeah, another quick, three questions. So, which of the functions modify the object? Let's raise hands for none. Oh, come on, Kailan. You know it's a three question. Raise hands for all of them. And just three of them. Oh, I see, I have scared all of you. Like, nobody's even trying. So, the correct answer is all of them. Right now, I mean, obviously, again, this is reading. It looks like it's checking what the value is, but this code also doesn't exist anymore. Now, all the is are replaced by parts, because that's what the function actually does. This one tries to parse the value in the string. That's why it modifies it. And this one is const, because the result variable, somebody noticed a small problem with the const, so the result is mutable. So, again, another important rule, which somehow people seem to miss, it should do what it seems to say, what seems to be the logical explanation for the code. So, if it kind of says that is value, it should just check if it is value and not said something. Yeah, somebody else apparently doesn't understand what const and mutable mean. The language says that the object doesn't change. The way I understand const, it means that for the outside, the object conceptually doesn't matter. If you, for example, have some internal cache, that one can change, but from the outside, the object doesn't change. And for this object, which change without changing, without making a visible outside change, those should be mutable. That's why it was wrong, because it was using mutable for something, which was visible from outside. And other expected stuff, we have class for reading bitmaps by pixels. You can access it using scanlines, and somebody tried to be consistent, so if you have things function getPixel, you get the Y argument first again. I have got it wrong so many times. And finally, which callbacks get called? Will somebody still raise hand or should we just skip this? Does somebody want us to tell the answer? I mean, this is normal code, it's in the code ways. You all of you sometimes deal with it. Yeah, it's the last one. It kind of suggests that it registers callbacks, but this is kind of, again, moralize repeating the same idea. The names should actually say what it says. This does not register a callback, it sets a callback. The note below is also sometimes it's kind of confusing. Sometimes people tend to learn things differently. For example, this is, again, a matter of taste thing, but I think function should be called get only if it actually gets the data. Maybe if it reads it from disk or something. If it's a simple accessor, it should not say get because it just does trivial stuff. It matters, for example, for performance because you can see from the function how you can guess how complicated it is. But this is one of the many things that's a matter of taste and people will disagree. And I kind of think LibreOffice codebase is kind of lost on this one because we have so many get functions which are just what I want. I wanted to mention it. I have some more examples, like this is kind of the same rule or rather the same recommendation, just different technical means to get there. I suggest avoiding very generic term. For example, calling classes data or whatever. That's generally a bit idea because when somebody will be looking at it, what does it actually mean like data? Everything is data. I also generally don't like use of the auto keyword because if you look at the code, unless it's obvious from the code, what does it mean? You will need to find out what is the type. I personally use auto only for generics if they need it or if the code sometimes makes it obvious if it's the begin and iterators, it's auto because nobody cares what the actual type is. Sometimes we do. The other section is various magic, mysterious values. There is an example of a code from Noel. In a writer you can get content notes, but sometimes you can say false if you look at the code. What does the false mean? You need to look at the function. Here in the function you still need to understand what point and mark mean, but those are writer terms if you actually look at the code. That's easier to remember what point and mark is. You don't need to remember what point and mark is. The same vcl has Xormode and you can say true false and you can do three combinations of true or false there. You need to look at what that actually means. During writing the scale back end when I do it internally I use enum. This is much more readable. You look at it and you see that it won't just invert, which is the same like here, but it's asking just to invert. And this can apply even to plain booleans. Sometimes it's better to use enum with just two values because it's obvious like, for example, case sensitive, yes, no, it's better than true false because who knows. I mean, for common list function OK, you can remember it, but if it's not common list function it's much better to just see there and yeah. Every programmer tries to be smart sometimes and we then end up outsmarting other people or even ourselves later. I personally remember some cases when I was looking at some code thinking who was the idiot who wrote this code and I look at Gitlog and it was me like five years ago when I was trying to be really clever. I mean you have probably all been in cases when you were struggling with writing code, but I have usually struggled more when trying to read code because it's harder, so if you try really hard to write something clever than it will be too clever for you to later read back. So there's this root rule about keeping simple and stupid. These are again real examples my nice stream operators that kind of write random values because you need to check what the type is. I have even seen assigning to return from getX. I don't know where I got it from, but I remember it so well that even though I have forgotten the place, I still remember being totally confused by it. Yeah. There were just some examples. We can have some rules which get implied from is, of course these are these theoretical ideals in reality. We sometimes don't have the time there's the line or we just don't need to do all the stuff right now, so there are also as I said, it's a matter of days we need to argue with the other person because it's just not worth it and in reality nothing is perfect, so whatever API we design, there's going to be some problems so we need to stop sometimes. But as I said in the beginning this is an investment your colleagues will think less often you're an idiot if you write better code that sometimes we'll have and if you don't really care what your colleagues think of you, it can say it's the problem of thinking that you yourself are idiot if you find yourself in git log I still remember I still remember that time prefer not to, but it happened and yeah, so if you don't care about at least bill selfish and think of yourself in a year it will come back even to you and even after all this stuff it can be difficult to agree on stuff sometimes people have ideas it looks nice and then somebody else comes and has a completely different idea just writing I ran into an idea which I ran into decently I would like to comment on how there is theory and then just somebody comes you may have noticed in last couple of years people writing in a kind of strange place not point reference, but point reference and this is supposedly a good idea and you can find an explanation that it's more consistent it has a simpler rule and probably something else so people are starting to use it and I was like this is weird, but there's arguments, but now I don't see it that way so and this is like for example, it's not intuitive unless you happen to about a spaniel or one of those languages you usually put modifiers first so how many of you how many times have you greeted somebody today by saying morning good we just don't think like that so it's not really consistent because how many people put static somewhere else and finally this is why sometimes people get try to have good ideas but end up with bad ideas because sometimes the stuff is hard and there's a misunderstanding I think this better rule about putting cons to the right comes from not actually understanding the rules for parsing C declarations which admittedly is quite a mess can again achieve I think messed up that one that's what it is so one rule is if you put cons always to the right of the thing then you always know applies to the thing on the left but that I think comes from somebody who doesn't know the rules because the actual rule is there is no rule, just use the existing rules because if you can read this stuff you know what's on the left is the value what's on the right is the pointer so it applies here as well this cons means that the integer that the pointer points to is cons this cons means that the pointer itself is cons no need for that extra rule yeah I know this is the last slide, I just wouldn't so this is complicated we are all humans so we messed up so we still will be handling the code that was written by people 20 years ago by the way I had it on the slide I don't know if there is somebody responsible for documentation while doing this I noticed that we link to the open office org style guide by saying that it's trustee guide trustee old guide can somebody please fix it like that's old stuff based on those rules some of the really broken code was written can we link to it by saying this is for historical rules and maybe we don't need to follow it because if we forever try to be consistent with the stuff that was written decades ago we will keep being mess if you just go to wiki development it says trustee old open office guidelines something like that can't just have like a jumper page which says these are not our guidelines that's how the code was written originally you don't really need to something like that yeah I know but this this page is big enough that I just wanted to say it publicly without just maybe somebody has a different opinion on the guidelines it's kind of it I hope that this was some of the useful kind of not that I look at it it sounded a bit like a rant but I hope some of it has been useful maybe like next time you will feel too lazy to write something appropriately maybe like we'll think of this rant and maybe you'll think better of it hopefully well so I think it's been useful do we still have time for questions? well in the meantime if somebody has stopped being shy and actually has a question you can ask questions? yeah so thank you for your attention