 Ok guys, good morning. How was last night? Did you go to the arcade party? Who went here? To the arcade party? You only talked it? I heard that it was quite crowded and people went to bed quite late. So thank you very much for coming to this talk. I will introduce myself first. I am Manuel Garcia from Argentina. I work at Aurora Fire. We are a development shop that helps other people. We build things for other people to deliver. This talk will be about specific tools to help developers to improve two things. One is the quality of the code and most importantly the education of how to learn why you do it. The agenda will be to talk about what is an interest as an introduction and why should we care about it. Some issues that many developers run into that this tool can help. Some rules on how we can categorize them. Then we go into a specific tool that is called sulking to learn a little bit about it. How to use it and extend it and also what is next with this tool. First of all, to set up the grounds. Many of you are developers. Many of you probably develop in other languages before Solidity. You have great tooling. Then you went into Solidity and probably spent a lot of time that could have been spent adding features, building, delivering. With tooling, debugging, I heard that some guys from Biddle created stack trades recently. They announced it. And also Truffle announced a debugger, a more advanced debugger. I remember back in DevCon 3 that the tech lead from Ogre said that he was going to pay, I don't know how much, to anybody who can build a debugger. But it took a couple of years. So Linter is targeted to analyze a static code and analyze all the structure by creating the text, applying a grammar and from that grammar being able to analyze many many many things. So this what it does is start them doing a white box testing as it is considered some practices. And a tool like Solidity will allow you specifically to go through all the structure of Solidity code, being able to analyze specific semantics of the language and run it through a battle of rules and see what warnings errors you can be avoiding. And all of this of course without having to go to compile deployed smart contracts which is much more time consuming. And with no delogs, no delogs. Some benefits from using a tool like this are that you get to increase the productivity, you get to deliver more, things get more shit done. And as a team you can share some decisions about what you care, what you don't care and if it is not included let's build it, let's extend it. This is more, you get code that is more readable, not only for you, for the team, but also given that 95% of the code is open source and out there, when we do open source well we tend to do things right. I have seen that many many times, people becoming great developers when they started working on open source. You get to have pre-code reviews given that many things just appear there before getting the PR to be reviewed. That of course makes the life cycle of delivery much much faster. And one of the very important things is that you might be many developers in the team but the code is like coming from one team, you don't care from who. The code is the same, following the same standards. That is about coding. Also you get to know very early and be able to identify problematic patterns instead of working a few weeks and then identifying many files and you know the rest. And most importantly thing here, at least I find more importantly because I've been using Linter since Java, back in the days. We don't go to the documentation too often. With a Linter that can give you a feedback on what you're doing wrong, you can get very easy to the documentation of what you're doing wrong. You learn and you don't have to run again into this problem. So by having this feedback you learn and you learn a lot. Some of the issues that at least I think that many developers run into they are at least, well I wanted to identify top five. When you don't have conventions you get to have a code that is quite different for each other for all the files, the developers, people get very angry. They say, fucking junior, what is he doing this? Low liability and efficiency. This goes not much for the code style but also for some patterns that are not effective as an execution complexity that can be completely avoidable from the beginning. And then say, okay I didn't know about this bunch of practices, I didn't know about this bunch of security vulnerabilities that are already documented and explain how to be avoided. I don't intentionally add that to the code but well if I had somebody watching there and if it is a robot that tells me I don't have to spend time from other co-workers. And the code reviews take too long because you have reviewers, each reviewer saying, no I like things to be done this way or come on this is an issue that is very well known or you are violating a best practice that has been identified too early. What rules this tool has so far? By the way this tool has like two years now? Around two years? Yeah. So we can categorize them in three. One are style guides, second are best practices that are this first tool the first is more oriented to the solidity, the second is like any programming language and the third are security. Some examples there is like, okay I mean styles with spaces, with presentation and many other rules. Best practice is sequential value complexity and use variables, functions and security most importantly some very well known and documented rules such as re-enterancy, not being clear when you call contracts that are not written by yourself. So yep. And here, okay we have some references. There are consensus with the guy a long time ago. So that guy is quite well documented and we were able to run those rules into this lender. And the second one is a solidity style guide by the language itself, the documentation. I wanted to show you some rules. So if you go to the documentation you can see a lot of rules that are already implemented. There are quite many and some references. This is great that if you have more references that are written in text documentation we can go and program them and include it in the lender. And when I say we is we, it's completely open source. This recommended, okay I would be getting back to this. So this is about soaking, a tool that was built more than two years ago by a guy who was migrating from Java to solidity and he found like a lack of these very basic tools. He got into a parser, a grammar parser by some solidity grammar that was built by Federico Bonn. I don't know really you two guys, no? Another guy from Argentina. Well, early discovery is priceless. It increases the willingness and happiness of doing code reviews given that the reasons that I explained and shared earlier. And this is the solution. You just go to GitHub solution so it's not that much important. How to use this is extremely simple, you just install it and you have to initiate the config file for that specific project. Then you can add it to your tooling to like, I don't know, packages and you can say okay, run linter inside the cycle of the continuous integration so you don't only run it locally but you also run in the CI. And from there this configuration file is quite open. Previously it was more opinionated but we had some feedback that it was like too noisy sometimes so some teams suggested to remove everything and this thing was open sampling. By default we remove all the warnings so you can go there and start setting up. The configurations are presets of rules. You can have the rules by default are like none. Then you have recommended rules that when I show you the rules there was a column with checks on which are the rules that are recommended and the other ones that you can add manually. Also it had quite a big prefactor recently to allow plugins such as other linters. The first plugin is Pretier. And allows you to extend with some other rules. Okay, there you go. So basically three properties right now. I would in bold recommend it. When you start with these devices like what I'm doing I don't have any rules. Probably in the future we will change this. Plugins and rules you can customize if you don't agree with the presets you can customize to get different type of errors or different type of rules. You can add more rules. It's quite flexible. How can you extend this and some other information? There has a plugin reference that you can follow and implement your own plugins and contribute back. You can create rules. It's just a JavaScript file. I can show you later. And one important thing that the guys from Aragon we send them a yard. And the bread said okay it's very nice but we have many, many projects. So we would like to have one definition because we have one team of many, many projects. And we created a concept of shared configs which you create, well a file and you just publish to NPM. And there you go with some presets and in the future you can start your project and I would say okay I will use Aragon down preset or noses preset. It has integrations with many ID keys some of them are kind of a pain to do but it is evolving and well the core developer of this use beam because sometimes he keeps a shit about the other ID keys and it has been integrated by default in open sapling and soon with the new version of Trafford that allows plugins and that you will have like optional in default plugins it will be one of the first plugins to be installed by default we have been working with these guys for quite some months. So let's see if I can do some demo here. These are the contracts of a project that we worked with some time ago it's a decentralized exchange based on the Dutch auctions or the book. The file was all that I was looking for a project I don't know this from this procedure a long time ago so the code is completely not the code that we have right now. You install blah blah blah then you ok I have to delete it so I will jump this and you get an output like this but such as ESLinter you can format the output so I can run like in somewhere here there format table Thanks for the full size and you can see here contract by contract sometime of the lines where this is happening of course that if you can integrate it with an IDE you can just jump into that the rules that you are writing here from this rule you can go to the documentation learn about it you don't do it again and you cycle you cycle you cycle until at least you get to know this set of rules here are some examples that we shared in the presentation because we are not going to have time again these are JavaScript files are not very hard to implement and I wanted to share this with you we applied for an Ethereum Foundation grant given that this is made with a lot of love but we have to make this address and we will be adding these features one of the things is separated from the CLI so if we have a library we can embed it in things like remix the remix team approach to us to do this and we need to do that it's coming the traffic plugin also some refactoring and very important to have an auto fix however this is dangerous because if I auto fix and I don't know what I did wrong I am losing the opportunity to learn well improve the documentation a lot that is very important and some plugins like having GradSpec that would be extremely awesome to have meaningful output when you have a resource or when you interact with the contract and more things that are requested by 7 okay this will be all of that I am going to do half of it thanks