Scala best practices I wish someone'd told me about - Nicolas Rinaudo

all right so I'm here this afternoon to talk to you about best practices in Scala and just to give you a bit of background on me so that you understand why I actually can talk about these things I'm the CTO of a company called busy dough we recently merged free completely different teams one doing node one doing Java and when doing Scala and we're trying to come together with the same processes and technologies it's working out about as bad as it expect but we have finally agreed that scarra was probably the language we all wanted to use and this is giving you pretty interesting perspectives because I'm getting to see talented developers that know nothing about Scala or functional programming struggle with learning the language and rediscovering all the things that really troubled me as I was learning the language so I'm seeing lots of problems that keep coming up and I'm writing down these problems and solutions to them and this presentation is the best ones the most common ones the most interesting ones or the completely not one that I want to share with you so the way this is going to work is I'm going to show you some code you are going to have to work out what I think is wrong with the code explain it to me if we can or if you don't have the time I'll just give the solution I'm going to tell you what's wrong with it how to work around it and in the next one so let's get started it's a very first bit of code that I want to show you is this so hang on again right so what why do you guys feel that I don't like this code I'm just comparing two arrays in saqqara now there's a bit of a hint often the title of the slides is a good idea but what the answer is going to be so here quite obviously the problem is with array comparison can anyone tell me why this is probably not great okay the main problem of that is it doesn't actually work array is the only collection in the entire color collection library that doesn't have a working equals method so comparing arrays like that is going to not work ever and we know that we as kind of developers we have had that problem before so we don't use a razor when we do we don't compare in that way but to beginners to people who come from a Java background or a JavaScript background or any other background these doesn't make any sort of sense this is completely nuts the reason doesn't work has to do with the weights encoding the JVM arrays have reference equality not value equality it's not super interesting it's just it doesn't work so instead of using equals for arrays use same elements and again you have to know that and it's going to buy you some time if you don't know it so I've shown it to you here and if you didn't know about that great I'll just save you hours of painting production right so that was my first problem with array compare regions and given the fact that this is canadaís I'm also going to try and for everything one of this problem explain how they are fixed or improved or not at all in later version of Scala and so in for array scanner to that 13 has immutable arrays which behaves sanely with requests to equals and not some of the stuff so if you're using immutable array is perfectly fine the mutable arrays even in dotty as far as I can tell are completely nuts and and try to stay away from them if you can right so this bit of code which looks perfectly fine does anybody have any clue what I don't like it come again right so this is not the first time somebody gives me the answer probably should change this slide this is completely correct but not the point of the slide again there's often a hint the problem here is that I haven't type annotated my method so he could return any time in the compiler you can try to infer it and best time you can infer the best type it can infer here what you'd expect it to be option of a especially given the fact that I have named my method as option it's actually going to be a sum which is not a massive deal most of the time if you have a sum it's a subtype of option so it's alright but it could be a problem say if this is a library and I were to publish that then the type of the method actually changed and you break binary compatibility just like that so when you have public methods public members type annotate them because otherwise you will eventually break something and the types are inferred are not actually the type you think are inferred or at least not not all the time so just fix it that way put an explicit type annotation and then everything will accept just fine this is kind of improved in scanner free because implicit members have to have a type annotation but at the same time implicit are being deprecated in scanner free so doesn't actually change all that much so this is still pretty much a problem in 2013 and it's kind of free as far as I know and do two type annotation on any of your public members Unicode operators this is problematic can anybody tell me why so first what is this code supposed to do this syntax here is expected to read create a tuple whose left member is 1 and whose right member is 4 divided by 2 and this is what happened if you wrote that using the ASCII operators and the documentation tells you that the ascii operators and their Unicode equivalents are exactly the same there they are in fact not the same this does not compile but if you were to use yes key operator composters fine so the problem here is very subtle the problem has to do with operator priority in Scala where the rules the rules are a bit weird and hard-coded but if your operator starts with an iPhone with - then it's going to have lower priorities and say divide but this corrector here does not start with a - so it's not actually the same operator as the ASCII arrow contrary to what the documentation explicitly states so this is very confusing and it is but most of the time to use the ASCII operator instead even though it looks much nicer with unicode characters there are ways you still have a nice display you can use fonts with ligatures you can use some advanced editor's such as Emacs have pretty printing but it's not going to be my problem much longer anyway because it's deprecated in 2013 so if you guys like me had rules to turn all your ascii operators into Unicode because you like that you're going to have to revert that because it's not going to apply anymore enumerations what is wrong with the way this is implemented first does anybody not know what enumeration is okay we're going to assume everybody does does anybody know does anybody even know why this is problematic I couldn't quite hear that I'm sorry that is a very good answer where to start this is a lot of problems is that mostly the whole thing is problematic but the one thing I'm going to focus on because I think it's very important is that once you have written your animation like that where you have declared an enumeration of type status with members okay and not okay then this code is going to compile without any sort of warning you can pattern match on the value of type state status dot value and have a non-exhaustive pattern match it's going to compile and it's going to fail at runtime and we don't like it when things fail at runtime especially since in saqqara we tend to assume that per match is smart and he's going to warn you whenever it's not exhaustive this compound without a single warning he crashes at runtime it's everything that's wrong with with a lot of the errors that we have in so don't do that don't use an immigration used use seal trade hierarchies instead where the way this works here is have declared the sealed trait sealed means that they cannot be any subtype of status declared outside of the file in which status was declared so the compiler knows that having declared okay as a subtype of status not okay as a subtype of status and those are the only subtypes of status in this file that can not possibly be any other subtype of status so the compiler knows now that this is not legal and he's going to warn you that you shouldn't be doing that and it's been going to tell you that it's going to fail on that value so we can give you quite a good error message just because you stopped using enumeration so don't use enumerations ever just one thing this is actually a warning not the computation failure something that's pretty important if you want to write correct scanner turn on fatal warnings I have had a lot of bugs found that way I've never had a false positive scanner sees very smart that way warnings fix them it's very important it's kind of free might even chi duplicate enumeration in favor of the enum keyword have seen discussions on that matter last time I checked he was not a proper tickets there was not a proper pull request on that but given that having sex this weekend lots of things I mean I think this week it might actually be going on now I don't know but this is something that might actually disappear from the language filtrate right I just told you CEO traits were nice and this is very similar to what I showed you before but I believe something is wrong with that code does anybody have an any idea why yes you're in the back it louder thank you so Barry's not final and the problem with that is when you see a sealed trait and I've just given you the definition sealed means you can't have a subtype you can't have a direct subtype outside of the file in which type was declared but direct is very important here most people don't really realize that but bar is a direct subtype of foo and you can only have bar as a direct subtype of anywhere in the rest of the code bar itself though it is not final so you can go into an other file and declare a scepter you can declare a subtype of bar and foo bar here is not a direct subtype of food because there's a level of indirection this bar in the middle so this is correct this is perfectly valid this is exactly how seal is supposed to behave it's also for people who have just learned about sealed not at all what you'd expect and it can be very surprising so it's not a huge deal and sometimes it's what you might want to do but you have to know that it behaves that way and unless you have a good reason for subtypes of a sealed trait not to be final to make them final or show themselves because it's a good default it's not an absolute rule but it's a good default unless you have reasons to not follow that role right so solution is to prefer final co-defendants and as far as I can tell nothing's changed in that says you know or dotty about that right how'd it break data taps so I showed you that just before it's basically the same code and now um something's wrong with that something's a bit weird with that yes you in the back right so this is a very good answer but just a wrong slide very soon so keep that answer and then answer it I think it's two slides down the road I'm not going to repeat it because I don't want everybody to know the answers to the next trick but no the problem here is that this killer compiler can some time in for some pretty wonky types so here if you create a list of stages okay instead it's not okay you'd expect the type to be list of status and instead you get this abomination which doesn't really change all that much but again this is from the perspective of somebody learning the language somebody who's new to the language and trying to work out how the bloody thing works and when they see that they can't help but think this is magic and it is magic a bit and it's not what you'd expect and you don't understand where you have that and the reason for that is perfectly clear in a coherent it's even possible for some people to explain it I'm going to attempt it not sure was he going to get it but the reason this happened is that because here is going to try and find the closest possible subtypes that is super type that is common to both okay and that's okay one of these types is status because okay and not okay extent status but that's not all because by virtue of being case objects okay not okay also extend implicitly series of all and product which you don't need to know it's absolutely not interesting at all its implementation detail but it means that the least this abounds so the closest to the types that is common to both of them is product with serviceable with status it's an implementation details that leaks out to the user who really doesn't want to hear about that and who gets rican fused and when you have to explain what I just said to people who are learning Scala you lose about 50 percent of in there yeah okay skies a bit magic I don't want that let me get back to JavaScript so that doesn't really work and the way to trick the compiler into doing what you expect is to have your ADT extent product with variable because all of sudden magically okay do extend status and product is serviceable not okay as well but both of them but status is also a project that n is reasonable and so the least upper bound is going to be status so this works this behaviors expected there's kind of three kind of improves on that by trying to hide it so the enum keywords will by default not return the type that you expect a return the super type but it still can happen if you use that if you use constructors directly details are not super interesting if you want to read about that this is clickable once I link the slides at the end of the talk you can go and have a look at how this works but so dart makes this better but it's not fixed it's just kind of hidden under the rug that was your answer so what's the problem with that case class and the answer was this case is non final and if it's not final then you get really weird behaviors that was in a sense your answer right so an example of my behavior is foo being non final I'm allowed to extend it here and have created a class bar with two members I and S which are in some strings and I maps to Foos I personal problem and then we have the additional string member and this means that this code here is going to compile and it's going to return true which is not what anybody's saying would expect and I've actually taken the most obviously the easiest example to understand because what happens if you put these two whoops sorry back there if you put these two in a hashmap is that one of them is going to have already other and you're never going to figure out what and when that happens in production and you don't know why you're losing elements it's happened to me I hope it doesn't happen to you it's a proper nightmare so there's a reason for that because I promise then you know that it explained why this happens if some of you guys have some Java experience what happens here is that foo being a case class it gets a lot of synthetic code lots of methods generated for it such as equals to string hash code all these kind of things and so foo has an equals method that is implemented in a way that makes sense to basically wraps an int so if we have two foods I have to insert have the same values and both of them are equal and that makes sense but when you extend when you subtype foo then bar inherits from the same equals method and so when you call that the method that's going to be called is it's a method sorry this is a bit fiddly so maybe equals method defined in foo which doesn't even know there's an S field it's a string so this is absolutely normal this is exactly what's expected but you know what's going on it's also super confusing and then it really does make the language feel like magic so prefer making final case classes there's a reason why this is not the default it apparently is there's one person in the whole entire words so does declare non final case classes and has a use case from it that person is apparently much in other ski so when that happens you don't get to change it I wish I wish it did change but unfortunately that's nothing's changing in either 213 or dot e so when you declare a class make it final please that's going to save a lot of pain in the end custom extractors right does everybody know what's a custom extractor is I'll take that as a yes so what's going on here is on declaring an object extract some within an apply method for any sum he's going to return a value of type option of a and this allows me to use extracts I'm in a patent match and this is really very wrong and does anybody know why when I found out I I got kind of angry does anybody know what's wrong with that nope okay have fun working it out so what happens here when you do that this code here he's going to compile no problem even though it's quite clear that given the fact that my own apply method only takes a sum it's not defined for none it's quite clear that here if my o isn't none which can be Jesus this is going to crush at runtime because a pattern match is not exhaustive but the component doesn't know that somehow and this will fail at runtime it's perfectly valid code but the compiler cannot work out that it has a problem so so reason for that was explained to me baby boy is done to really work that thing and I'm not going to try to explain it so parent matching exhaustively checking is quite wonky in Scala 2.12 and in order to avoid this kind of problem that solution would be to never define custom extractors if you can do that but if you can't try to make irrefutable extractors return some resident option because that actually fixes the issue and you do get the expected warning here this kind of free makes this whole thing a lot better there have been a lot of research done on exhaustively checking for pattern matches and so the problem is completely gone in dot E and you don't need to worry about it as soon as you move to scale of free but until then be careful with custom extractors they're weird structural types do I need to give a quick quick explanation about what a structural type is does would anybody like that think up of nods okay structural typing is for those of you who have used dynamic languages this is duck typing but in a statically typed language this allows me to say that my add one method here will accept any type provided that type defines a def get methods that returns an int and then I can just call that method because the only thing I know about that x value is that it's got a cat method so I get that and add one that's what I returned and then conveniently I can define define this case class notice how its final important that wraps an int and define a get method or not and I'm completely allowed to pass wrapper to my advantage even though I have not defined any hard subtyping relationship so structural typing is a way to do subtyping without having to declare it beforehand it's quite convenient it's it's a great tool but in Scala is suffers from a few flaws does anybody know what the flows are yes right okay so the rent man said reflection which basically covers my to point this is implemented in Scala as reflection so the compiler knows this works because it knows everything that is in wrapper it knows that wrapper has occurred so it knows this can't fail but at runtime he's going to have to use reflection to dig into the values that I received extract a method object call that manually and this is much more expensive than not doing anything so it has a runtime cost it's not massive runtime cost and that should not discourage you from using structural typing when it makes sense but the other problem is that at least on the JVM this might not actually run at all because it's possible and Jai being in the JVM to disable runtime reflection as a configuration option through security managers so the compiler is going to compare that there's no problem with that code but I'll run time you're going to find out that you can't actually do that then you have no way of knowing that in advance so the preferred approach is type classes and I'm having a bit over-enthusiastic here so I don't think I have the time to go through all the slide if I go through this whole thing if anybody wants to know more about the type classes I'm going to explain that after the talk but I want to cover a few more of these before before we're stopped so I'm going to skip the explanation if you know what the type classes use that instead of a structural type and it's kind of free does overall the entire virtual type API but I don't think it changes the core of the issue because the default implementation still relies on reflection reflection and I don't see any ways that it could be anything but reflection from those cases I don't think it's going to be fixed it's improved that not fixed at all exceptions can anybody tell me what's wrong with these two bits of code come again right so persons might throw a number from that exception because most strings are not actually married integers and element at might thrown arraigned except an exception or some such thing because I might be outside of the arrays bound and the problem with exceptions well there's not very many problems with exceptions but the one I've chosen to focus on here our first thing is okay so this one is not entirely honest but it works wonders when you're trying to explain to other people so what happens very often is I'm working with a Java programmer reviewing the code that I wrote in Scala and when they get invited into itself for an exception and I'll point out that maybe don't want to throw an exception maybe exceptions should not be used and they look at me like I'm crazy I've been doing exceptions my whole life in Java why should not do that what's wrong with them and then what I do is I ask them okay would you use a go-to statement in your code course not nobody uses go-to statements there are famous papers written just about the fact that you should not be using go-to statements and then you ask but well then what's the difference between a go-to statement an exception can you explain to me what's the critical difference between the two all and most of the time I have they get playing for 30 seconds then oh okay and they get with the exception we carry on so this is not entirely honest on my part because there's very many differences between exceptions and go-to statements but there are a few critical similarities the first one is the problem with a go-to statement is when you're at the label or the go-to statement you have no idea where you're coming from you could come from anywhere in the source code so you don't know your state and this is something that you have exception as well you don't know where the exception was from you have no idea you might have mutable states that he's not gonna say could expect so you can't know and this is very similar between go-to statements and exceptions it's kind of inverse for exceptions because when you write a go-to statement the compiler is going to fall if there is no Associated label so you know when you write to go-to statement that is going to go somewhere with an exception is basically I'm going to bail out now somebody catch me otherwise crash don't know don't care your problem and it's even worse you don't know that anybody's going to handle it you can't you can't check that so that's the first reason why I don't like exceptions it's it's essentially a go-to statement for all the wrong things that matter it's unchecked in Scala so this is specific to Skylar and a few other languages but in some languages such as Java exceptions are part of the type signature of the method that declares n so the compiler can tell you well you haven't caught that exception you haven't dealt with that error case so please do that and otherwise I'm not going to compile but we skele the compiler completely ignores exception you have no way when you call the method that was an exception you have no way to know whether you have actually dealt with all possible error cases a mad crush on run time and you have no way of checking that and lastly it's referentially or PAC which is a very barbaric term which I'm going to explain now so referential transparent referential transparency is a property of code that we really like because it helps us reason about code at the local level it means that when you have an expression you can replace it by whatever it evaluates to without changing the meaning of the code so you can ignore whatever else goes on around the whole thing and focus on that expression that all that matters so an expression is said to be referentially transparents if you can replace put what it evaluates to in a variable then use the variable everywhere else and throwing an exception if it was refreshingly transparent wouldn't means that this to implementation would be the same because in that one I have a test that doesn't make much sense it's never going to be evaluated but if false is true then I'm going to throw an exception otherwise return to and the other implementation does the referential transparent test thing where it's going to put the result of that expression into a variable and then it's going to use them in the rest of the code then obviously that doesn't actually work out the first one we're evaluating terminate the second one fails so these two expressions are not equivalent and so throwing exceptions is not refresh a transparent and you don't want to desert in your code because it leads to all sorts of headaches you should eat as much as possible prefer encoding your error types inside of the return type of your view methods so concretely rather than throwing an exception if you want to convey the absence of a value return an option if you want if you have some sort of fancy error code or things like that put it in an either so the right side of the either is a successful path the left side of the user is worth it's the error code your message whatever and if you have if you absolutely have to work with exceptions like you're doing some Java interrupts for example try is going to help you it's basically a neither that contains an exception on the left so if you have to use exceptions use a try rather than Anisa and unfortunately nothing changed in dotty about that now I was starting to put together things that we have said before this is one almost completely varied way of encoding so this is a very simplified ADT which we talked about before which is meant to encode all possible error cases when you try to connect it to a database and in order for the whole thing to fit in one slide I've just declared two possible implementation one which is the sequel you try to run it's not valid and the other one is try to connect but lost the connection please try again and something is not ideal with that implementation but you know it does have all the thing I've said so far it's a cell trait it extends products we say reasonable case objects everywhere it sits it follows all the rules have given so far but it's still not quite right does anyone know why or how you could improve on that okay the problem is a lot of API in the standard library rely on exceptions to convey errors mostly try in future and you have lots of libraries that will use future or will use try and you can't stick your DB here error in that of inside of you to try so in order to work around that what you're absolutely allowed to do is use exceptions but you're not throwing them just tagging your type just tagging your type with an exception and so DB error is now an exception which product answer usable and you can absolutely stick values of type DB error in the left or in a tribe's array or in the future it's not a problem at all so they have a trick that but it allows your exceptions ADT is to be a lot more usable when interacting with the standard library right now the return keyword okay what's wrong with that aside from everything well done the return keyword so there's lots and lots and lots of reasons to not want to use written we have the whole go-to statement thing again it's basically same discussion direct referential transparency again same discussion but mostly it's just completely insane it doesn't not at all do what you think it does coming in up well we're going to go through that right so this code here looks kind of sane this is what somebody who's come from JavaScript for example Matt right it makes a lot of sense you have a list of int and you want to map on it and add one to absolutely every single value in it so you create an enemies function which returns n plus 1 I unless you know to look for return this makes a lot of sense but the compiler doesn't quite agree it's telling me that I've said it was a list event but we should be an int that doesn't make much sense to me mapping in a list should return the list but compiler is often more smart than I am so I'm going to trust it and play along so I do what he does well he suggests and now this is not a list of incidents new complaint should sorry should be list of nothing when nothing occurs in the type that you have inferred something's really really wrong and I have no idea what's happening here but I'm just going to follow zero messages back to it well you found a list of nothing but I really wanted an end to what the hell so I don't know what's going on I don't want to know what's going on I don't want to understand what's going on I use return it makes no sense you're going to try to understand at some point you won't you will fail you will you will remember that slide and you will think I should not have tried to understand it don't don't do it it's a nightmare don't use return ever just scrub it and there are possible improvement in scanner free in that non-local return statement might be forbidden I and what that means so maybe it's a good thing I don't know implicit conversions right so this here a method defined as implicit means that it's an implicit conversion so whenever the compiler is going to find a string that he would like to be an int he's going to call this method and turn my string into an end this looks pretty nice it's pretty it's very fun do you know what's wrong with that right so if you muttering it I'm not going to hear it without you I came up with the answer oh absolutely will for an exception because it lets you write beautiful code like that foo bar divided by 2 and the compiler is going to be very happy to compile that and carry on as if nothing happened and this is basically you lying to the compiler returning it right I know better than you do this string it's actually an int and this is most of the time not true there are infinitely many strings and infinitely many more strings that are not instance ensuring there are inch so this is going to break eventually sooner rather than later and you never want to do that the main problem being that this implicit conversion is not total so if this was total so say transform ins into floats it's iffy but it's ok because it can't fail at runtime still weird if you're getting the types to lie to each other but it will not fail at runtime but this is this is horrible I don't want to do that instead well you could do this remaster thing sorry you could do this rhiness to think and be explicit about your conversions or you could just try not to divide foobar ways to could make much sense it's also a possibility so this is at least in Scala - there's a reason to have implicit conversions is this is how all libraries are exposed Ted classes will allow you to add syntax this is how you can have the map method when you have a factor instance for example it's very nice implicit conversions to enrich existing types existing types are okay they're also completely unneeded in Scala free because you have extension methods so as soon as color free happens stop using visit conversions the compiler is going to fight you over it anyway because it's going to ask you to enable the compilation flag and then to be very explicit about it this kind of free implicit conversions are kind of frowned upon and this is a good thing implicit resolution so I'm going to go through that one directly because it's a bit subtle what happens here is after define a type config which contains a port for some sort of network configuration and I've defined a get port method that for any config value in scope is going to return the port so that way you could implement a default configuration here so by default my configuration is going to have port 8080 and if I call get port like that then is going to work out that the default implementation here and your default port is going to be 8080 it's quite convenient mechanism but in skylight suffers from a pretty big problem which has to do with implicit shadowing so here in another object I define a new implicit value of a completely different type default config here is of type config default config here is of type int the only thing they have in common is their name and that should not have an impact then the name of a term when you resolve type but it does when you import both a1 and a2 you get the dreaded could not find implicit value for parameter blah blah blah and this is very confusing because this is not what you'd expect it's actually quite clear what happens when you remove the implicitness of this if you were to import both a1 and a2 and ask the compiler to use the full config is going to tell you well it's ambiguous I have it both from a1 and a2 which one do you want to use and this is very clear this error message so when I don't have an implicit thing stuck in the middle I understand what happens but what actually happens is you get could not find miss Perry for parameter and this is black magic to most people who start learning the language this is extremely confusing and the bad news there is no real workaround provided that you don't have a perfectly unique name it's going to happen eventually and you can't guarantee that you're going to have a completely unique name anybody can be using same name as you and with worse thing is here when you do that you might not know that a - declares an implicit value of the wrong name so you might have no idea that you causing the problem you don't know what you're importing because you're importing everything so this is very confusing to beginners and what happens it's a nightmare to explain it so when you do it when you have to declare implicit values give them city names really long names with with your name in it Nicholas's fancy fubar instance for type int look city but the whole point it's an implicit value nobody's going to see the name use not supposed to many play the names of implicit values so so it's not a problem but it's still not perfect somebody might also be called Nikolas and have the same naming convention as I do so that might still be a problem luckily in Scala 3 first you have import implied which means you know that you imply importing implicit into implicit values so it's less likely to happen because you can't do it by mistake but more importantly implicit name shadowing doesn't exist so the problem just completely gone in scot-free so it's major improvement string concatenation can anybody tell me what's wrong with that excuse me okay well um here string concatenation I'm using plus to do string quick animation this is this is a mistake because plus he's kind of insane it doesn't behave very coherently so here I have a list of string and I plus bar it so I do not string to it and this is going to return a string which has a value not super interesting but it's going to do that on the other hand if I have a set of strings and a bar that it's going to add it to the collection and it doesn't have the same type at all so this is weird when you know what happens underneath you understand it then you go of course without thinking but when try to explain that to somebody who's learning the language of course it behaved that way could not work out why the person is going to look at you like you're nuts and he's going to go away never discolor anymore and I'm not even talking about these absolute nightmare where you add to a list of int and the compilation error is well I expected a string why why would you expect a string again it makes sense when you know that any two string add either thing if you do know that any string add it does exist and you know what it does I'm sorry for your pain I went through it as well I think it's deprecated it is deprecated in 2013 has been removed from 2014 magically back in Scala free I'm not sure why I think is going to I think it's just that error free hasn't been rebased on to the two dots in standard library I hope I hope but so instead don't use string concatenation use string interpolation instead this is first I find a lot more readable and it doesn't have the same problem because it's not using plus and also yesterday Daniel I was making the point that string concatenation is much slower than string interpolation so there's as well if you if you care about efficiency use string interpolation in conclusion how do we enforce best practices how do we make sure that all of this stuff that I have shown you and there's a lot more where that came from I've just picked the best how do we make sure that this thing doesn't crop up in your code well first code reviews I know that a lot of people don't actually like Kirby news but there's some very solid research that proves that code reviews actually does drastically reduce the amount of defects in software so when you get a slide you can click that it's going to link you to the publication's to that effect do code reviews it's great and it helps you avoid these things and it helps you teach them to people who don't know them use tools that automate the finding of these problems so that's a bunch of that's I think I think that at the moment that's all that exists but the landscape keeps changing and we're Perry big on Tooting at the moment so I wouldn't be surprised that by next week we have another one but at the moment we've got scapegoat what remover scale info scaler style so can I say especially if you go through Rubner issues personal subject which makes us kind of kind of sane again and calorific so all these tools are going to make your code much much more reliable also switch to scalar free as soon as you can because that you could see it fixed a lot of the problems that that I had this were my favorite but well either bad or best practices depending on which way you look at it there's a lot more than them and I'm pretty sure I don't know all of them so if you guys have things that you think I should have talked about and I haven't I'd love to hear about them and I'd love to learn a bit more and I'd love to include them into my next version of this talk or into the website that I've created to go with that I wanted to thank these color contributors and Dottie get a channel especially a mouth I don't know whether he's here but he's basically written all of the future improvement sections he's basically leaving database we never asked something like how does that work oh not a problem here publication here to get here mud requests five seconds he knew zero rails by heart I don't know he does so he's really quite impressive but if you're wondering about its kind of weirdness in the language or how these winners are going to be fixed in the future these together channels are really really great more information so the slides are already available here and if you want to have proper articles on all of these rules and more there's a companion site at this URL where I took the time to write these things down properly not just a slide can follow me on Twitter I work the Phaedo blah blah blah this is all done with remote by Rimmel Gia's and I don't know if Robin are still here I saw him before chat is an amazing tool that will make sure that all the code is so in these slides is correct and evaluates to what you've seen because it's actually executed when the slides are compiled so it's not possible to get it's like to compile and not show the truth and do we have any questions thanks [Applause] yes yes thank you thank you first and I have a question raises color fix and is it possible to add such cases what you described to be automatically reported right so that's the point of the automated tool so was the first part of the question where is color fix because wait what is or where is what is what you question what is good coming in okay right and so these tools will automatically analyze the code and failed your build if they find one of these parents they're pretty opinionated what remover in particular is really hardcore a reports you can turn off some some things that you might not agree with for example I know that what remover is going to fall any code that defines default value for methods but sometimes quite important to have them so I don't actually agree with that what so but but all these tools will fail your builds if they find some sort of pattern and you can pick and choose and add whatever you want and get I mean I think that all the things I showed here are reported by one of these tools gentleman in the back I have a question about using try I mean in every place where exception may happen I have a experience that such pure way may occur in some try orgy so you write a code and you'll end with code where in every place you should somehow handle a try didn't you think that do you have any experience that maybe it will be some threshold that okay in these cases I should use a try but there are some cases where throw exception is completely okay right absolutely this is a very good question so exceptions are absolutely ok provided they actually are exceptional so if you run into an error such as CPU not found it's ok to crush your prime not going to be able to recover from that but the exam for the game here where for example string to int and number for that exception most strings are not in s-- it's not the exceptional case it's a common case that this is a failure so this is not an exceptional exception it's an expected exception and you should not use an exception for that you should use a return type but for anything that you're not likely to survive from or that just doesn't make any sense just let that go absolutely let fatal errors be from that's not a problem at all don't we have much of a choice anyway I mean you don't have a seat to you just what am I gonna do anyway and for the question the man over there oh sorry right ok so I don't have time for public questions I will be here if you have further question don't hesitate to come over and ask them and that's me done thank you very much [Applause]

Channel: Scala Days Conferences

Views: 16,459

Rating: 4.8993711 out of 5

Keywords: ScalaDays, Lausanne, Nicolas Rinaudo

Id: DGa58FfiMqc

Length: 48min 48sec (2928 seconds)

Published: Thu Jul 11 2019