 So good morning, everybody. Welcome to our little safety session. And to our first talk with Philip and me regarding coding guidelines, shouldn't we comply or what should we do with it? So yeah, I'm Nicole. I'm a functional safety expert for, I think, about 15 years now. I've been a software developer before. Developing embedded software mainly in the context of safe applications, a little bit automotive, a little bit military, what you do these days. And actually, we founded our little consultancy about three years ago. And we're working mainly in the context of functional safety, cybersecurity, and hopefully more and more open source with it. My personal main aims are really applying functional safety with a common sense, so not over, I always call it over-fusification. So we really use common sense. Make your system or software better. Make it more reliable. Make it more safe. Don't even focus so much on the compliance point of view. And what I'm also aiming is applying more and more continuous integration, continuous deployment principles to save or secure software for me in the embedded stuff, but generally having functional safety and continuous principles combined. Yeah, I guess this is also the way how we came in touch like three years back, more or less taking the path from different perspectives. So I'm Philip. I'm currently a technical business development manager for embedded open source at Bosch. So I'm going through different events, trying to bring open source into Bosch, Bosch people into open source, checking this where do new projects make benefit for Bosch in the product development. And yeah, I'm also the ELISA project TSC chair for this year. I'm Linux Foundation advisory board member for the Linux Foundation Europe, so not for the larger one in US. And personally, I'm not like every time since Linux user, I guess I started like 2005 fish around it or so. But I was always using open source tools this more the way how I came into the whole thing. And what we also did was using Linux and automotive since more than 12 years. We brought our first device into the market, which is a 2.628 kernel, I guess. And this was also the first time where we came a little bit in touch with coding guidelines, MISRA rules, and so on. And we saw that it's not always easy to make use of it also in open source components. We've struggled with deviations and so on. So I thought that's why I also jumped on when Nicole and I had the idea to talk a little bit about this. I guess I don't know how many of you, maybe we do a short very first poll, how many of you are using coding guidelines, MISRAC are related on a regular base? That's good, most of you. So I don't know if you see too much more on this. So if you learn too many new things because we touch it more on server-based, but I guess this gives us room for a discussion later on. So everybody who lived at the hand at least has a chance later to live to once more for a discussion point in this. From the agenda, we try to get a little bit of the motivation to talk about coding guidelines and principle, what leads us there, where they help, and so on. And for those, I mean this may be a little bit boring for most of you at the beginning. So what coding guidelines are, what it basically means, and how you can explain it to others who are first not familiar with it, what are intentions about it. A little bit on what you may need to consider for choosing guidelines and so on. And going into some practical examples to say is there really one coding guideline which can rule all of them? Already taking this upfront, or of course, they typically apply to a certain language and not to all the languages you see around. And yeah, and then at the end, what you should do for a documentation part? Yeah, that's where we go on. So from the motivation perspective, we see especially in mission critical systems, it comes in. So in automotive, even if you don't have safety, rated parts, it comes in. There's often regulated environments where a lot of things are asked to be followed. And that's it, that sometimes the people come in and say, OK, here's this coding guideline. You have to apply it. And then you see the source code and things you have written by intention and purpose. And you figure out not exactly everything is just giving a full fit. So it's something where you need to start evaluating or adapt certain guidelines. But the thing that you really make up your mind early, so we'll talk about this also a little bit later. And there's often predefined, that's predefined coding guidelines without a common sense. So you shouldn't use them without this part, without understanding or just taking it for granted. Yeah, then motivations also, it's really this strict alignment to the coding guidelines. I guess the strongest one, which I saw in the past was always the Ms. Rossi, which comes also often safety critical discussion. Elisa, as we are looking into the Linux kernel, mainly this information up front, I guess we will not make the Linux kernel MISRA compliant, right? So and I guess, well, nobody maybe wants it anyway. And yeah, so therefore you can end up with deviations. And first of all, now let's go over to what is really a definition of a guideline because we're talking here about coding guidelines. And I guess Nicole just takes over. Yeah, so just let's start with a definition. So what is a guideline generally? So I very often get the perception of people, yeah, oh, there are coding guidelines and this is the law of the project and I can't deviate in any kind of way. And yeah, as I'm not a native speaker and as I think a lot of non-native speakers still have this nice little advanced learners dictionary in their bookshelf. Yeah, just to look into what's the definition of a guideline and actually the dictionary comes up with two definitions. One was yeah, it's a set of rules and instructions that are given by an official organization telling you how to do something. So for example, yeah, the government has drawn up guidelines for schools during the pandemic. Sounds pretty official, right? On the other hand side, the dictionary I also give you the definition saying something that can be used to help you make a decision or form an opinion like yeah, the figures are useful guideline when buying a house. It won't say in detail how to use these figures and that they are set in stone but it's more, yeah, a guideline in the sense like we use them in the coding guidelines. So it's a guideline to help you make a decision. So what does it help you? It helps you make a decision about yeah, how to streamline your code, how to make it look unified, how to improve the readability through it to have all the constructs all the time in the same way from having your curly braces like you have them from the intendations for how to use certain constructs of your language. In the end, it shall make your coding easier because you don't need to think about special things. You don't need to come up with something creative that differentiates you from your colleagues. Also mainly to avoid common mistakes. I did code heavily in CEC, has a lot of pitfalls, it gives you a lot of freedom and a lot of room for creativity but if you're in a rush, if you don't know how to use certain constructs or even sometimes it's very platform specific or compiler specific because it's not defined for 100% in a formal way. So yeah, the coding guidelines should just close the gaps or tell you to avoid certain constructs that might be problematic in your coding language. And actually yeah, it's guidelines or style guides it's nothing that comes to us the first time when we use coding languages and natural thing in languages if you think about punctuation. Also our words, the way we construct our sentences are not 100% clear sometimes and that where punctuation comes in and yeah, our favorite example is yeah, let's eat grandma or let's eat grandma. It saves a life. And also applying coding guidelines can save a life in our context. But what we typically also observe that there's a large hesitation when coding guidelines come in and it feels like being regulated, being governed and it makes my life much more complicated as a programmer, right? Because I get this additional tool. It's not fancy. I need to read through things and then suddenly I made something by intention but yeah, I guess that's something we may start screaming and also sometimes really it looks like it doesn't make sense and I guess these regulations you may find it in your processes of a company and some more areas or in a government as a way say, well, they try to find a rule for all which is not always the best idea. I still like that in Mr. Wright said you should avoid go-to by any sense so it will look for any go-to which you're right by if you look into the Linux kernel. For example, there's good reason to have a go-to in most likely, right? For just saying, this makes the structure easier. It's better to read and for, but the guideline itself cannot say don't use go-to unless you know what you're really doing, right? Because then you will say, I know what I'm doing and that's not the case. I mean, if I talk to my kids, they also say, oh yeah, I know what I'm doing. They say, oh, can you drive a car? Yeah, yeah, so sit down, drive the car. Oh, what do I have to do? Yeah, right, but before you work, once you are already know what you're doing. And yeah, they're also the impression that they have to be applied at all costs and this is something which makes us really nervous and will say, no, that's not the thing. But there are also really good reasons to go for this. So it can, for example, close certain specifications and certain gaps, right? Things which the compiler does not find. You know how to use it, but it's just some guideline on top because the compiler never made it to this point. And it could also be, if you have hardware specific architecture, something you could say, this is generic, but there is something which you have to avoid because we know that the hardware has certain limitations. It cannot detect certain memory barriers and so on. And there's also the low hanging part of it with increased readability and avoid quite strange constructs so that you really go for it. And I guess we come to also some more coding style related things later doing the presentation, which I guess a bunch of you may use typically always and do not even ask for it, at least if you're in the next kernel area. And yeah, this can also violate until we have certain pitfalls in the language. And this is basically just the same thing. And yeah, it's not also, even if it's sometimes static analysis, can also go into the dynamic behavior of the code. So in the end, it's still really there to make the coding life easier and products more reliable, more robust, secure, whatever. And what I see in there, if you apply these kind of things, if you, I don't know, another poll, how many of you spend quite a significant amount in reviewing source code in pull request, much request patches and so on. That's not as much as before, but still quite a lot, but at least I remember when I read through, I can sometimes, so if I have people in there, I can say, oh, first clean up, look how the rest of the code has been written. How is the intention used? How do you define things? And it costs really a lot of time. You spend just for these formalities. And for this, I see all their projects out there which we just define rules and say, please run this script upfront. It does certain checks for it, right? Or use this tool upfront. Or even stating, we will use this tool. You may not be aware of this tool and cannot access it because it has some proprietary licensing in there. But there is a good enough first step in there when you use this one. This is freely available. And just get your clearing, run through it, and you're much faster. So this is really the intention of it to have not only yours single one person maintainable code, but having others in there, having peers, having reviews in this. And this saves us a lot of time by just giving this to a machine, giving this to a program and let you help going through this, right? And then it's the time to select a coding guideline, right? So yeah, I hope you're sold now but why you really use coding guidelines or at least think about it. And so how will you choose the right coding guideline for you or for your project? And actually the first and foremost thing that you need to think about is what is beneficial for my project, for my product? What do I need? Is this rule even applicable to me? Do I want this rule? Do I need this rule? Or do I need more rules that are previously there that I've looked up them somewhere? And then really consider the objectives like Philip already said. Does this address my understanding of a readable code? Does this address really all the pitfalls that I might run into? Do I need maybe to add more information for certain deviations that I might accept or maybe certain levels of skills that I need to add to use certain constructs or deviations of some coding guidelines? And actually just after that you can consider, hey, is there something around that I can reuse? Is there a similar project that already has coding guidelines that I might want to look into? Is there a de facto standard like, yeah, the ubiquitous misera that is used by my industry that I need to look into and there might be stuff in there that I can reuse for me? So actually, yeah, first step really is look into what's beneficial for you. Then really look into just what you want to have, really meet the objectives, what you need to have for a coding guidelines, and then, yeah, look what's already there. And as you want to automate as much as possible and we don't want to do reviews just to check coding guidelines and all that stuff, having an automated checker is really beneficial, believe me. So, yeah, most common coding guidelines and standards that are around, yeah. I'm coming from the safety world. I used misera rules before I actually knew the word misera for me. Some things were really clear or let's say very clearly communicated in the project how things are done here before even new misera and misera mainly focus is still on C, C++. There's a lot of modeling stuff in there, so it's, yeah, it's a classic safety domain stuff. There are the cert rules, at least in my perception, they are more common in the security-focused projects. They are even available for Java and Pearl, I've seen. Actually, when you look into misera, when you look into the cert rules, in the end, they address the same things. You want a reliable code, you want a readable code, you want to avoid pitfalls of your coding language, so they are very, let's say, they're not completely similar, but they're very like cousins pointing you into the same direction of how you might want to work. But that's not the only coding guidelines around, so we have a few more for you. Yeah, I guess we all almost all come from the embedded space or mainly working embedded. I don't go into full details of this, I just wanted to say there are guidelines for various kind of language, right? And it doesn't need to be mission critical, it can also be just in a server environment or other parts, so it would be like for go, C, sharp, and even if you, and what I recently heard more often is like, if you're programming in Rust, you don't need the coding guidelines because a lot of things are already in the compiler, but actually, if you develop the Rust language, then you also will follow coding guidelines, style guidelines, and how to do this because it's crucial in such a large-scale project also to have a common sense and have the basic things considered. And this may be for those which are developing a Rust compiler, but also who would like to extend the language, right? And this one is just mentioned here, and sometimes there are also just related things, so I took some part, we have it here. The last one is the check patch, write the check patch per for the Linux kernel is not really like it gives you any programming hints, but it's mainly for concentrating on the style because here it's really, really crucial that everything looks similar. On the contrary, I also remember when discussing with engineer thing, oh wait, I'm just writing test code. So I don't know why, but sometimes there's a perception that test code may end up with a different level of code qualities than the one which you bring into the product. Well, it's like, wait, it should be the other way around because you don't write test code for your test cases, right? So that's the other way. And I also added Python, and I especially took the Python in the robot framework because within Bosch, I cannot speak for the whole Bosch, but I can speak for some areas where we went in and we said, if you look into, for example, your continuous integration, there need to be rules that you continuous integration. Your tools are also properly assessed, right? So even if you run code checks in the source code for the product, you should also check things which are in this CI CD development flow. And we made a rule for some project where we said, you are not allowed to introduce a new tool as part of the CI if it doesn't come with linting. So we will always have lint checks also and if you then add some tool for the CI, the tool itself can also again check linted. And by this, it helped us also love to increase the quality of the tools. There are also some examples which are more rigorous. So the next three, Lisa, and I think here it's quite nice because it's better to argue on this. So for the Zephyr project, for example, SCR does, you have a smaller code base and there are also guidelines described and the TSC and safety committee in there also said, we would like to follow certain guidelines. And if you search for it, there is a bunch. I have one example on the next slide, I guess, where you really are considering how to update things but it's also hard pass, right? Because you need to reach the people, sometimes it looks strange. If you are an artist, you're heavily resource constrained and you know how to do things so you may think differently about how the source could be right. Will you initiate a variable explicitly or do you save this amount of memory again? These are things to be considered. And on the contrary, this XEN project, I don't know, have attended the XEN for safety talk at the beginning of the week from Stefano, I guess he was pointing it out. So they are on a pass to have a MISRA compliance, for example, and they say, okay, we can do a lot of these things because we have just around 50K lines of code and we have a community which is really committed on a lot of these regularly because they come from a secure safe perspective in the project also with a majority of the users. So, and what they, for example, do, I mentioned this, they use the covariate scan for now but you need to be a member in there and you need to see certain things so it's not fully open there. So you can see some results if you go for the scanning part but it's not that you can pre-scan things easily. So for this, they said, run the CPP check, up front on your contribution, this already helps to reduce potential pitfalls a lot. Right, and here, one example that it does not always make sense are that following rules strictly we can cause you some headache. This is also one which I took from an issue on XEN project. There's a MISRA rule, I think it's 3.1 and this is how you never use nested comments, something could go wrong. Unfortunately, when someone has written the original C Commons or C++ comment they were not considering URLs and somehow also the MISRA rules were not considering URLs. So for this, if you have just an HTTPS address in there this will be a MISRA finding. So if you want to make an extra reference this is something hard. But maybe we jump over to some real-world best practice examples. So I hand over to Nicole again. Yeah, so yeah, as by the abstract we promised you some examples. So I had to come up with some and actually I don't like to play the blame game so I needed to come up with something for myself and I haven't been coding for a while. So yeah, actually this is my grill in my kitchen and the story behind this is the first thing or one of the first things my partner asked was hey, this is cool. Can we put an alternative firmware on it? And I was like, hell no. But let's just assume we took this as a project and created some source code for it. And as you can see my little piadina here it has some nice grill stripes on it. So I don't only want to have the normal temperature curve on this cooking stuff I really want to have it really piping hot sometimes with a boost function to get all these nice little stripes on my piadina. So how could this code look like? And for sure it's safety critical because I don't want to burn it down the house so. So I like my code to be as short and as clean as possible. So I have three main functions. Yeah, that don't do anything at all state where I just touch the touchscreen unintentionally and nothing should happen. I have the case that I want to use a boost function. I have the case that I want to use the normal heating and actually when I use a boost function the normal heating function follows after that. So in my case I say, okay if I have boost run into boost just don't break go further into normal heating. If I have normal heating, yeah just switch the boost skip the boost go into the heating function. And yeah, if I don't want to do anything just break leave this function. And as I'm a safety person I always add an error handler at the default case. But yeah, my miser checker would blame me for not using an unconditional break after my boost case. So yeah, what should I do? So on the one hand side I could say yeah I make my code longer, I add a break and I add the function for heating into the case of the boost function. Actually I don't like this. But yeah, in this case you really have two options. You could try to argument why you leave it the way it is and you have the way, yeah make it compliant and change it. So for me my decision was I don't want to change it so officially I need to argument why I deviate here from the rule. So I said okay, is it on intention? Yes, it's on intention that I don't use a break here and it doesn't make the code quality lower, it doesn't make the code unreadable and it still meets the objectives to have a readable uniform and understandable code because it's an easy function. And so also it's as short as possible you can see it on a glimpse in one moment what this switch case is doing. So in this case, yeah you can really do two things. If you prefer the compliant way, change it. Nobody would blame you or you give a reason why you don't want to change it. You could also implement this function with an if else. It's easy, so I'm always in a rush so use an if else statement actually I only want to reduce the heating or boost followed by heating. So yeah, quick and dirty. Actually this would on first intention do what I want to do. It switches on the boost function when I choose boost and follows the normal heating temperature curve or straight goes into the heating temperature curve. Yeah, and once again, the Misra checker is blaming me for not ending my else if construct with a general else. So do I need to change this again? Maybe, let's try. So yeah, I'm just add two lines called the error function in the else path. And actually now it doesn't work anymore because every time I'm unintentionally using the touch screen and I want to do nothing, I get an error. So oh yeah, I forgot to really use my do nothing variant. So yeah, adding my do nothing to it, I see okay, now it again does what I wanted to do. It doesn't go into error state. And actually yeah, complying with my coding standards helped me finding an error. And I think we all know every day life, these careless errors, they just happen because we're all in a rush. The function itself sounds easy enough that you might do it even before your first coffee. Maybe even your reviewer won't find it because it's so easy, I just reach through it yet. That's what it should do and go on with your life and then you have a problem and fixing stuff afterwards always is more hassle than doing it beforehand. So yeah, it can make sense to use MISRA in the end or MISRA like rules. So and how can I do this? I guess first of all it's also important to mention that simply implementing the rules like you said can really cause also to damage your code. So if you just follow the rules and did everything, not always the intended functionality remains, right? So I remember things from the part where we tried this and some of the engineers in my group did and suddenly we found regression then in testing because it was just from the code change that nothing behaved as before anymore. But whenever you have, it's very important when you deviate inside, no, I'm not implementing it that you documented. That you put a comment in there which explains what it does. I try to blame some of my, not directly blame some of my engineers which I had in the team but I try to blame what we have done. So I was looking for good examples and actually I can say from the source code which was quite old, I was heavy-tating to show the comments because nowadays I didn't understand the comments anymore. So be careful in which kind of comments you make that other people may understand it also later on. It's good also to really do this in code reviews so not having it also as peers so that also the peers understand what you do and it could be good intention also to take these kind of things and do a specific tag which is maybe project specific in which you work on because it may not comply to all thing and you may want to reuse the code and also consider that it's independent from the static analysis tool because a lot of these static analysis tools also provides you a way of writing it but you never know when you change your tools so then you also have to add this and see at least a chance to get it more generic and a bunch of these tools support this. Right and it's also good to have some kind of ticket documentation if it comes to safety, critical work, I say this is a documentation, you get a traceability in there and this will help for later assessments. Then yeah, set so from a structured way you have this in the code, you put some reasoning, you may add there, you need to document your design decisions later on try to do it wherever possible and then if you've done this this would be just a normal way but we are in a safety critical, mission critical environment so there's just a little bit more on the ratification of this deviation because you really do this and for this if you see on the left, the larger block that we have and overall objections of the coding guidelines and we need to make sure that these are not violated and the thing is not like you do it afterwards like you maybe sometimes figure out you come for a nice thing you would like to select a certain tool or something and then you start with the evaluation after you have already in your mind selected more or less a tool and then the evaluation is pointless because it always shows you the results which you want so in best case, come up with these parameters before and this gives you a better chance than to really discuss about am I deviating or do I need to change something? Then yeah, I said about the statement and see this is the upper part of it and the last part would be the documentation of certain safeguards that are in place to avoid violation of coding guidelines of Jaxus so this means like could also be pre-compiled statement and other things which you could actually bring in to make sure that there is no chance of violating things and it's not directly related to this but what we for example also did was we changed that in the GCC we said minus the error also we have say every warning turns into an error which also just helps because it's not direct warning but like these kind of things are too considered and the last thing this is really safety specific I guess there is the underlying part so it's you need a clear approval this may be additional hurdle on this to have a last ratification on this but typically there should be either depending on your organization how you do it there should be senior developer maintainer safety manager whatever you have in there who should work on this and as we were on this punctuation part in the beginning and the example why it's important I found a statement from Edgar Allen Poe from 1848 who was saying something about coding guidelines and he said that coding guidelines are important all agree but only few know how comprehensive the extent of it is important and if the writer who neglects coding guidelines or mis punctuation, mis punctuation is liable to be misunderstood then yeah this goes on like this I really can just read through it shortly on your own I found it very nice because already there it was mentioned this is a long time ago and he points out to punctuation what I still also want to say is Edgar Allen Poe I hate him for his say the sentences which he writes so I would say this is not going through is to pick a coding guideline or style guide right and by this I guess we come close to the conclusion of it yeah so yeah I'm also not a big fan of how Edgar Allen Poe writes but yeah punctuation makes it at least readable kind of so yeah do we need coding guidelines? Yes I think there's no doubt that we need them in some kind of way do I need to follow a coding guideline standard for 100% all of my life all of the time for each line of code? No really yeah I'm a fan of common sense use your brain and so what else do we want to tell you on the long term? Yeah please spend more time beforehand when you start with coding guidelines when you choose your coding guidelines define what you really want to have define the objectives of your coding guideline and maybe even when you define your coding guidelines come up with some examples for your team come up with maybe even deviation rules what how you need to document your deviations or when can you deviate actually and also reconsider your coding guidelines if some rules start to bother you or bother your team on the long term yeah lessons learned think about it adapt it change it use another one maybe add another coding rule if you need it so yeah it's a process and please for the sake of maintenance and continuation of a project document all your decisions because they won't be forgotten then so this said thank you everybody for being here and yeah we'd like to hear your comments questions opinions on that thank you Thank you for the good talk does you know safety or security certifications allow those type of deviations? Yeah the big seabird certifications yes with a certification, audit or assessment you will get the question do you have a coding guideline how did you come to this coding guideline and how do you apply it and where are your verification reports and actually when I'm in an assessment and I ask my customers how do you apply your coding guideline and they say I have a hundred percent misdrug coverage and I don't have any deviations and I say okay I don't believe that your code is really doing what it should do and that is working and then I get the deviations and usually yeah as long as there are there's a reason behind this and they're documented all will agree that you need sometimes a deviation from a rule we also have one up here may okay yeah not I mean maybe one in the back and another one yeah maybe in the back and then in front yeah yeah thanks for the talk very a lot of things touched I think one more thing that I observed that pushes back developers from using that it's not that developers don't want to follow them or it's about how hard to integrate these checks and example with caverity and do you think that in any nearest future we will get something like a clang flag dash dash check misra like we have with clang tidy or with clang format or anything like that I guess we don't get a direct thing in there I don't believe in the because it's also also here we were very careful and just don't giving too much about the misra part because some parts are like standards but there are other tools which already have command line integration and then you can just say it may not be the full fit but like the cpp check is something which you can just integrate in dci pipeline or you have other tools which just goes through the repositories and just provide you with a report which have IDE integration so that you can use it with your Eclipse IDE visual studio code I'm not sure about an e-max and them integration but at least the reason ones which are more in this so they directly go you see a report you click on it jumps to the source code and you find this you can document things I'm hesitating to say do the documentation on the tools that what these tools sometimes enforce you to or want to enforce you so then at the additional step this creates a hurdle but I doubt that there will be full straight away integration but what you can do if you're a power user of it if you're using a company you can say I would like to have this and the more people say we need this this make the life of developer easier the higher the chance get that it gets in and we have a question in the front I have the microphone here so there's kind of two extremes I've seen in programming obviously ones no coding guidelines but in a practical sense the Linux kernel coding guidelines are short there's a lot of justification clearly written by developers for developers based on years and years of experience I've also was at one company that had a 50 page coding style guide that just had amazing stuff clearly some of which was very personal to the person who wrote it so is there I'm sure there is I just don't know how to find it maybe there's a collection somewhere is there are there people doing research on this so that we can actually have some you know really sort of a B comparisons if you do it this way you actually get a noticeable improvement at least something subjective ideally something objective you know I'm in Israel also provides justifications this is really good but you may or may not agree with all of those things would be nice to be able to say look it actually helps I guess you can and then you will not find the rule of thumb thing in here because if you make a generic statement on these kind of rules and you would end up with this one-size-fits-all t-shirt or socks and they do not fit one-size-all right that's clearly true yeah I saw that there have been studies again and again and even also around the I think for even from the box thing they do some studies around it right because they have a university touch in there as well so around the miserable there something about not really comparing all the different things and say this is the best thing of all or the comparison very good research area yeah that's what I'm wondering about it if there is some place that you can find research about that there is research if you look for it mainly I looked into some papers and they are like yeah there are coding guidelines all these miserable so whatever standardized rules and they're not as this beneficial as people think that's then the end statement and I don't I don't like the how they are constructed so I would have would love to have a more yeah yeah I'm seeing both sides and yeah I'm saying okay in this case it will be beneficial to that extent so but I haven't found a really good paper in it so I would have referenced one if I had found one but I don't I didn't like the ones I found yeah it's I mean it is really hard to do that because you actually have to have multiple people writing multiple things according to different standards and then you have to actually have something big enough that it can have defects in it and you can see defect numbers readability numbers all of that stuff yeah so maybe a big shout out to the universities so have a look into it and give us some feedback I guess we reached the end of the talk there's actually a question one last question oh sorry yeah there's a question from a virtual attendee I'll read it up have you thought about the interactions of coding guidelines with respect to code coverage if code coverage is present in the project could coding guidelines be disregarded in the end the code is being checked for coverage no hell no okay maybe one last question or okay just one last question so I have a question on how do you recommend adding coding guidelines to an existing project especially an quite an old existing project because I've had developers complain about two things one it makes far too many changes and secondly it breaks good blame yeah so what we did in practice for some parts because we were using pre-existing components we said any new commit should comply to a coding guideline this was one chance we figured out that there are certain components which never get touched for this part we actually came up but it was in agreement with the developers who said we would like to have a quality week so we were not organized at sprints at all or anything but we said here is a time of one week or two week and we said let's go the other way around when we often look at two critical parts and critical bugs severe bugs we said let's take two weeks just looking into minor trivial code quality things to just improve the overall quality and this was well received and we couldn't make it for all the developers because there are sometimes all this still firefighting guys in there but by this we got quite stable things also updated reduce things the worst thing which we wanted to switch things on like i said this was a week warning all vr all wr all so this was something where we switched it on we said okay this breaks everything it will not give us a product for a time well we may set up a set up just set up where just the diffs were taking and this helped a lot so i would say take incremental approach start with the diffs see if it's not enough see if you can get quality days or quality weeks and then improve it thanks okay thank you thank you