#8 - Effective Dart & Dart Static Analysis - Write fast, maintainable & consistent Dart Code

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hey what is going on everyone i'm wicked welcome back to my dart from novice to expert complete course in the previous tutorial we finally finished talking about dart packages as we're approaching the tutorials in which we'll start coding in dart in today's video i'm going to introduce you to some tips and tricks on how you can structure your code mainly on how to write fast maintainable and easy to understand dart code so without further ado let's get right into it beforehand though i want to send a token of appreciation to everyone supporting me as official youtube members especially to diana and michael aka aza on discord if you want to become a member all you have to do is to click the join button right next to my channel and pick your desired membership having that said let's continue with our tutorial now let me ask you a quick question has there been a moment in your programmer's life in which you looked over an old project and understood almost nothing from the code you wrote a couple of months ago if so this happened probably because you're writing unorganized inconsistent and overly complex code this is true not only with dart but with any other programming language out there from my experience there are three rules you should follow in order to start improving the way you write code be organized and consistent with your code write minimalist and simple to understand code and always test every piece of code you write the first rule refers to the fact that before starting a new project whether you're working on a team or a loan you should set your own code objectives like how you'll format the code how you're going to name functions variables when you're going to refactor the code how you're going to structure your files and directories inside the root of your project etc this might seem like an obvious step but believe me it's overlooked many times just grab a piece of paper and make a simple plan on how you're going to write your code it's going to save you tons of time when developing a huge project in the long run the second rule even though it seems self-explanatory is probably the hardest to achieve and follow during the development phase what i want to highlight here is that after you write a piece of code perhaps a new feature or a new function you should glass over it and check if you can make it more simple and minimalist by minimalist i don't mean writing the entire implementation into a single line of code by minimalist i mean thinking smart on how you can optimize the code to become simpler to understand and perhaps more performance efficient so the main idea would be to double check the code you write before moving on to the next step as i said this is probably the hardest thing to do since sometimes you'll just spend your entire day coding a feature and you'll definitely overlook checking the code again if it works in order to optimize it this rule also covers the fact that you shouldn't rush the development process i mean i know there are deadlines to follow but i really believe the key to success is being optimized i prefer writing three features of stable organized and minimalist code in three weeks rather than writing them in one week in a haywire manner then spending the time to understand what you coded and speaking of coding testing the code you write denotes the third and last rule i follow for a fast stable consistent and robust code flow i can definitely understand developers not wanting to test the code they write for a small app that can be manually tested each time they run it however for bigger project you can't really do that the idea here is that for each and every piece of code or feature you write there should be a test in which you verify that it performs as expected this way in the future writing more and more code won't slow you down by having to manually re-test all previous functionalities since they'll be already covered up by your tests you'll see what i mean when we'll start writing dart code in a couple of tutorials from now on since everything will code will be tested accordingly so basically in order to stick to the rules i mentioned before dart offers a list of guides that are linked to specific linked rules you can actually go ahead and enter dart.dev browse to efficient dart topic and you'll see all of the rules split between four categories style documentation usage and design so you might see there are a lot and by a lot i mean a lot of lint rules obviously i won't cover them since it would literally take me hours to make this tutorial instead i invite you to take a more thorough look over all of them on dar.dev website this is more of a holy bible of dart you should really get to read before starting developing apps as you already know from my previous tutorials in the dart ecosystem the dart analysis server uses the analyzer package to perform static analysis the file managing all of these for your package is the analysis underscore options options.yaml file which should be placed at the root of the package exactly in the same directory as the pubspec.yaml file now you might wonder what happens if you don't include an analysis options file inside your package will the project use no analyzer well no if no file is found the analyzer defaults to standard checks only so if we take a look at a sample analyzer options file you'll see that similarly to the pubspec.yaml file it comes with some fields worth discussing the include file provides the option to integrate the content of perhaps another file from another package to the current analysis option file you might remember from a previous tutorial we had this set to the analysis option file from inside the pedantic package meaning that all the lint rules from inside pedantic were included in our analysis options file the analyzer file provides a respectable amount of customization to our static analyzer for example we can enable stricter type checks exclude files inside of which we don't want the analyzer to do its job ignore specific rules while also changing the severity of them and we can also enable some experimental features inside the linter field you can provide a list containing some of the lint rules i showed you earlier however as you saw this part was already included with the pedantic package we added at the top of our analysis underscore options file and with that said it's time to end another tutorial of this amazing series i hope you understood how the static dart analyzer works and how it interacts with the analysis options file in order to make sure our coding plan persists during the entire development phase of our app the next tutorial will be really really important since we'll get our head into the huge topic of dart sound null safety one of the most important additions to dart language you really need to understand and practice as always if you like this tutorial don't forget to smash that like button subscribe to my channel and share the video with all of your friends and colleagues in pursuit of top tier development until next time as always take care wicked is out bye bye
Info
Channel: Flutterly
Views: 1,596
Rating: undefined out of 5
Keywords: dart, dart language, dart lint, dart linting, dart analyser, analysis_options.yaml, dart static analysis, static analysis, robust code, fast code, maintainable code, consistent code, brief code, effective dart
Id: xrG4sayxsuM
Channel Id: undefined
Length: 7min 30sec (450 seconds)
Published: Mon Jun 14 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.