In this episode of the programming podcast, we'll discuss static analysis and code transformation. In particular, we'll look at the difference between compilers, linters, and formatters.
By the end of the episode, you'll understand what tool you should use to improve your development experience and team processes.
Episode 15 - Compilers, Linters, and Formatters
00:00:02 - 00:05:08
welcome to the programming podcast. Here you can learn about computers in a brief and accessible way. I'm your host mean could get. Hello everyone and this episode of the programming podcasts. We were going to discuss three different tools. Rings talk about compilers called for matters enters. We're going to discuss how they compare to each other. And what are the responsibilities of each individual also on a very high level or just in a couple of words? I'm going to try to explain how these individual tools work so. This topic is inspired by many conversations. I have had with tens or hundreds of euro over the years very frequently. I notice the confusion between these. These these different tools like what exactly linter is or we'll just exactly the responsibility of the compiler very often. I see people referring to compile time errors. Linton cares and being unsatisfied that their winter is throwing a bunch of errors which is preventing them from running their software or deploying its production. So I'm hoping where this is going to address some of these confusions and we're going to have a good idea about when to use for matters when to use linter. What is the difference between these two? And how the compound time type checking fits into the bigger picture. Let me start first with cold for matters. You could probably not as that in community online in social media or even inside of your teams a lot of the discussions that are happening are around tax. A lot of the culture of your comments are related to syntax as well which is quite wasteful right at the end our software. It doesn't matter how he frittering. Whether is Britain one million lines of code or these long lines of quarter concatenation it into a single line of court generators to produce the exact same result right. It doesn't really matter but obviously it matters as a software engineers getting starts in a new cold base or reading Leaks circled. It helps us to remove this mental overhead to adjust to different coding styles. If we see consistent coding style everywhere we can be more productive. We can read source code much easier and this is going to improve your overall productivity of our entire team on the undersides discussing for hours where we should use tabs for spaces. This is probably not the most constructive and the most useful discussion out there now. This why they're calling matters. There are source code for matters which aim to enforce a certain convention that a team has agreed upon so the source called for matters to take your program. You're going to build an abstract syntax three. This is something that we discussed in the very first episode of the program with podcasts. Where the matter is going to take hours program which is pretty much drink. It is to build this abstract syntax tree and on configuration. It is going to serialize it into an equivalent program with normalized syntax. This means that other matters for some of these decisions where we're going to use space versus taps or whether we're going to put the opening brackets of the state much out right after the condition or you line. It doesn't really matter. The source code for immature is going to enforce this consistent style all across our called base. Now let's talk about compilers so there are a couple of responsibilities of the compiler but probably the most essential one is to translate our source codes to on the program from a lower level linkage. That's what's compiler is do some compilers which have compiled time type checking enabled. They're also going to make sure that our program is correct to some extent depending on some type annotations of individual expressions functions in variables so the fact checkers perform a bunch of different logical operations in order to make sure that our program is not going to throw any runtime errors that are going to ruin the user experience for our end customers. An example for that is let's say verifying whether we're accessing a property or evoking a methods of a variable which could could potentially be know as you know if we do that and this happens at runtime our program is likely going to crash and her during the user experience but if we catch this earlier during the process before we have shift our program to production we can prevent some very frequently occurring issues right so the compiler is verifying fine that our program is correct and also helping us to prevent issues at runtime.
00:05:09 - 00:08:33