 Hey there today, we're talking about linting and I don't mean the stuff you find in the dryer We're talking about linting your code today on cloud dev clarity And you're there. How are you? Well, I've already screwed up this Better and better every time better and better practice makes perfect. Hey, it's supposed to be loosey-goosey. It's informal Nobody's gonna care. Maybe they get to make fun of us. It's all good. They make mistakes, too Well, I've proven that Well every day of my life I prove that episode five check One mistake down I have five checkboxes anyway, I Am excellent. I am excellent. So linting big topic really timely topic Yeah, at least we'll talk about what it is. Yeah, at least for us So let's talk I think a little bit about what linting is for people, right? Let's start there I mean linting in general is this idea of having rules about how your code is structured and how it's written and how it's formatted and To try to drive consistency right and so the history of this at least for the typescript people I mean, there's linters for all sorts of different code Bases but for the typescript crowd, I suppose which is maybe more of our our target audience. Maybe not anyway There was TS lint back in 2019 they deprecated that in favor of ES lint Mainly as I understand it for performance reasons and to hopefully improve Reliability and support ability. Um, what's your take? So, I mean The the history of linters actually goes way way back So it's all about it goes back to I think like the sea days see yes And I've used them there. Yeah. Yeah, and it was I guess the the reason we had them I always find it when you understand the reasoning behind something it's easier to understand why we have it But so the originally we originally were using these because the first the early compilers When you had run something when you run your program through it it just choke and be like didn't work. Yes But you had no context So people created linters to look at your code to do static analysis on it to find issues before you ran it To have a better chance of the compiler getting through it And then then you could you know, hopefully the app is then gonna run and you can figure out Do you have logic errors or something? Right? Exactly. And over time the linters got smart or the compilers got smarter and they could tell you, you know error on this line or those kinds of things and So linters turned into being more about being able to do static analysis of your code and for To recommend good practices to to in order enforce good practices in your code and also a Lot of people use them and a lot of companies use them to enforce like coding style guides So I found this list of like where's some popular? Linters that are out there and I was a little surprised by the size of the list. I've got Ansible C C++ coffee script CSS dart Dockerfiles EPUB Erlang go graph QL Haskell JavaScript markdown NPM objective C pearl PHP Python Ruby SAS that's one that I yeah that one too type script Yeah, CSS comb was one that we used it that I used to use with Stefan We don't actually it's deprecated so we don't use it anymore, but yep Absolutely the thing with the tea with the TS lent the ES lent one that I know is where you and I spend most of our time in the JavaScript types world and That one was interesting because like there was we had one for TS lent and when the type script team Decided that this doesn't make sense because type script isn't about good ice cream wasn't about creating a new language They were about creating a superset of JavaScript, right and adding some tactic sugar And so they decided no doesn't really make sense Instead what we should do is we really should focus on making an ES lent Lenter That's where our investment should be in terms of a Lenter for JavaScript or ECMAScript Focus on that and have rules that are for type script But it all is runs through ES let through the ES lent tool, right? Yes, and so the team that was Doing TS lent a company from I think company was named planter They saw the same thing and they're like Yeah, it makes sense. So instead of us working on our own tool We're gonna just jump over the typescript guys So they switched over to and that basically the whole world kind of said that the JavaScript world said, okay ES lent is the tool that we should be using for doing linting. We shouldn't be doing TS lent in The context just of typescript. So this is not a replacement for everybody else, but it's just the context of Right, they just essentially broadened the scope And I think what then that helps with is if you use a particular Framework version or whatever there's a lot of times linting rules for that particular framework Which can then also help you especially when you're talking about a corporates or corporate or a company-wide style guide coding style guide That can absolutely make some consistency Yeah So what kind of things are people going to see when they do this like when they what kind of rules Do you see with the linter and well? It's so there's the things that are like definitely where you can get yourself into trouble like the things are Allowed in both ways, but almost always you want to use one versus the other and so there's the kind of like Are you sure you want to do this kind of rules equal not equal is one of the ones that pops into my mind really quickly like the you know that Notorious equal equal equal means it's completely equal where equal equal means it's sort of equal Whereas equal as assignment, you know that kind of idea And then there's stylistic things like I know In the PMP JS library we have ES linking rules and some of them I Might want to have some arguments with Patrick Rogers about some of them Like every file has to have one empty line at the bottom, and I'm like I don't know why we're doing We do and it is a common one, but I don't understand the benefit of it So maybe maybe I just need to do some more Google research on that one But But you know I'm just like it's annoying because I'll break the relent rule because I forgot to put a return at the end of my file You know it's yeah, and it's a fuzzy like there's the rules today because they because the compilers are So much better than they were years ago that it the rules today like I think the line is very blurry on What is a rule that is? Debatable and opinionated right verse. What is a rule that is like good guidance? So like for example There are some rules that will say that you shouldn't ever do you if you're gonna use promises You should always have a catch on your promise You should just do a promise and then have a then and just say hey I use the promise just to be able to write something asynchronously It's like no no you you should always have a catch there to handle that other exception And then then there's the argument of well to satisfy the rule that message that you're gonna get with a hit on That is just create a catch and they'll do anything in it. It's like right. That's not really the point the point, right? But you you can get away with it There are other ones though that and these are the ones that I like to me they get into my skin is When the language supports something so I can that case right the language support. I'm almost gonna like refute what I just said The I'm actually gonna refute what I just said, but this is the part where it's kind of like, you know, what is The justice on the US Supreme Court said years ago is like what is pornography? It's like I can't describe it, but I know it when I see it. Yeah, it's kind of like one of those things to me like it is when I look at a When I like the one that I just gave about it's called no floating promises Where you don't have a catch that's a bit to me That's a good rule and the one that we should all we should all pretty much abide by it because I mean you should handle your If you're gonna do a try statement You don't do a try statement to keep the component from breaking you're doing a try statement And you should finish it off with you know the rule of what should happen in the exception But then you've got other ones where it's like hey I don't have to put and type script and JavaScript support the fact that if I don't put an accessor on a member It's assumed to be public right and then it's like well No, you should always put a public there because maybe it's not explicitly known It's like just language characters. I have to type Yeah, it's like that's the way that's more mental math that I gotta do or the one the one that feels a great example is when you can have a Parameter on like a parameter on a yes argument Yes, so I do a constructor. I can use constructor and then open print. I can say private Argument is a string and that's all I have to do and what that does internally is come as type script says Oh, I'm gonna create a private member called whatever name the argument is Yeah, and then I'm gonna take the the parameter you're passing into the constructor I'm gonna sign it to the value of that private Instance so we can look at it and so to me you save yourself from writing two extra lines of code But it's also really succinct going I know exactly what that's doing. I mean, it's it's but the message you get back from the linter is Not everybody may understand this may be confusing for new people So you shouldn't use this and I'm like I call this bullshit on that because it just depends on the organization Like I can see if you are a very large organization that builds commercial software where let's say as an example And you have various levels of development expertise. You have new people right out of school You have, you know, very senior people and you know architect level etc. And they're gonna have different levels of knowledge about something I could see that an organization like that making decisions That for some senior developers, they'd be like, oh really but because you Potentially have this very large group of more junior developers You want to keep things very consistent and very understandable and so some of those rules So the ability to create those rules makes a ton of sense when you are one or two developers building software for some specific Project or whatever or you know internal project or something else some of those rules are so ridiculous I like consistency. Don't get me wrong. I'm actually a little bit Kind of OCD about my consistency like I will go back and I'm actually of I am of the mind that I like all my private Probably because I wrote C sharp first. I like all my private variables to have the underscore. I actually like that I'm one of the few I get it But I will go back and make sure they're all done that way and and it's because for me when I'm quickly scanning code I know. Oh, hey, I okay. This is that you know what? I mean like it just Works with me, but I'm a coder of one so I get to choose my own rules. I don't know what you mean Yeah, I don't know what you mean about OCD, but let me just So Yeah, we got that I'm right there. I'm right there with you and I think what I'm what You know so cards on the table one of the reasons we're talking about this is because in the world that you and I live in We talked about in all of our intros is we live in the SharePoint framework world quite a bit and and the last Week or two they've released a new version where they of the of the SharePoint framework where they switched or they went from On SharePoint framework 1.14 to 1.15 and in doing so they they finally dropped TS Lent and they replaced it with ES Lent But when they did that they took the advantage of saying well, let's go through unless add in a whole bunch of rules and Maybe they were already there as part of the argument Maybe they were already there and they weren't working which is not a part of the argument They have but the thing that that I mean for me that kind of irritated me was that There's a lot of opinionated ones that they are enforcing on us about coding styles and I think this This does open up a pretty good debate that that you that you could have and find out where people like what side of the of the aisle you fall on Whereas what is somebody like what is their role in that sense of coming up with those rules? So I'm like I'm curious to know that there to me There's like there's two or three different Swim lanes you can fall into a different buckets you can fall into at this one of them is in the case of the SharePoint framework They've gone through and they've built a tool where you work that creates new projects just for the SharePoint framework So it'd be like getting Visual Studio or getting like VS code But it's something that's creating brand new you're only using it for this one for this one target environment or target framework and They're defining a bunch of rules another scenario is Using ES lint and linting rules for like a company project a good example is what you're doing with with with P&P JS I Wonder I like I've got my opinion on it, but I thought I'd lay these first I'd let you go through unless you want me unless you want me to say something so you can refute everything I say I might do that anyway. No, but yeah, that's fine. I am big boy, but I cry afterwards. I just have to make it for another But I think that we I'd be curious to know like where you fall on the whole. What do you think? Where would you use it? Where would you not use like just a first question then ask you and put you on the spot Do you like linting in your projects or not? I? Yes very minorly like because I have a set of consistent things that I like to do Linting can help me just make sure that I've met my own Criteria right that I've made my code as clean as I want to make my Enforcing the rules that I like but I'm also a developer of one right So it's gonna be the things that the stylistic things and the things that I maybe make notice that I make mistakes on That I would like to just make sure I have a little extra set of you know Rules sitting there underneath that's just gonna keep me keep me honest keep everything clean by getting lazy if it's the end of the day it's like creating Like creating the employee handbook when you just hear a company of one Because when Mark Anderson and I first started working together he sent me the a joke employee onboarding Email letter so I'm just that flashing back to that where he's like HR would like to tell you You know it's just him and I but he sends me this like onboarding letter on my first day I was like you dork God. I love you But yeah, so it's just a set of like, you know a little bit of rules now if like say Sympraxis which from a development perspective is mark a little bit, but Derek and I Um You know like early on when Derek was writing more code with me I would have loved to enforce the try catch rule so that he couldn't write a method without try catching it I was just being bitchy about it like reviewing his code going. Um, I'm seeing 35 methods that have no try catching there. Please go back and fix that. Okay. Thank you but um but you know so from a stylistic point of view I could see a group of developers coming together and saying hey again similar to me wanting to have my own little Guardrails on certain things Great what I don't like what I'm really against is if it just doesn't matter so like type Assignments for instance, whether you do as type or type You know with the brackets around it before the you know for for the variable What the frick difference does it make? It just doesn't make any difference the transpiler likes both of them I don't understand why anyone needs to say You must do it this way or that way sometimes it's about code readability if you've got a fairly long line Having to do that as whatever with spaces in between it That's readability is really tough Whereas if you have the brackets it just pops out at you're like oh, we're doing type reassignment here and it pops So I actually kind of lean towards that method But I've done it both ways because maybe I'm at the end of like an object that I'm creating And now it makes much more sense to put as the type Sort of at the bottom of the line just because stylistically it's easier to read And I'm going to maybe switch back and forth between those two methods depending on what Surrey just answered me That's what that jump was about Surrey's like what what do you want between my apple Between my apple watch doing the same thing and I've got a al e x a on my desk right now I don't want her talking to me right now. So yes, I should have muted. I will note. So now I have a check mark mistakes Man, you can hear like when cj and I were doing our podcast there was always every once in a while you'd hear a Amazon al e x a we're just timeline. I'm sorry. I didn't catch that like a shot It's startled back out of me. It's never happened. Anyway, so that's that's sort of my viewpoint on it like rules that stylistically keep you consistent because there's a point being consistent or You know because you want to maintain some consistency and or things like the equal not equal one I take out because I I do a lot of testing like Object equal equal null which means either null or undefined and I don't really care which and I do that quite a bit and Is it technically right? It's fine. It works. It's you know, and I don't want to have to go and ignore put a lint rule in every single time I do that I'm careful enough with my triple equals that I feel comfortable not having that rule But I could see if I had a bunch of junior developers. I would maybe want to be like Maybe you need to very explicitly say you're going to do this, you know Yeah, I agree with that. I mean and I think the other thing too the the type declaration one or the type definition one I thought that that's a really uh, that's a really good one because I could be in the exact same file or in the exact same method And I could use it in both ways like the argument that they say is that if you're if you're using If you're in a react project, you shouldn't use the one where you put use the angle brackets at the beginning of the object because that's It's jsx or tsx And yeah, and if you're doing a web component you theoretically could be type asserting something that's a web component. So yeah No, that's legit. Yeah, I see that being a confusion But then I also see like if I'm in the middle of a method and I'm trying to pass in A number as a string or vice versa or a Boolean as a string And I want to say like variable as string. I don't want to do like bracket Boolean One of them is like what you're saying when I look at the code that your code should be I'm not pulling the card out that you know, I don't need to document my code my code documents itself It or it's it's clear on what it actually does But there's a well There's a bit of that right that I don't feel like I need to put I don't need to have a certain number of comments in my code If I look at I can understand like I'm good like I was looking at one of my students He was having trouble with something and he shared a method It was only four lines and I'm looking at it and I'm just staring like how what the hell are you trying to do here? I couldn't really was trying to do because the code was written in a way There's another reason why I say that but Why it was confusing, but I'm looking at it like you you should write it in a way that's actually pretty intuitive To some yep So to me the thing that was that where it falls down The thing my line in the sand of where things go is that I look at it as really is three different things So I look at it like in your case So let's use it if you're like a corporate developer or you're working on you have a team that's working on a project Right. I think rules and if you have multiple people working on a project. I think es rules Going as far as you want to go is perfectly fine Um, so like for example pmp.js There are two of you that are working on that project and it's an open source community Right community contributors too, which is probably the more important reason Exactly and it's an open source project. And so that open source project You want the the rules that the prs that people submit You want them to follow the same convention that you follow because you don't want to sit there We do the same thing in the docs for the share point the share point developer docs that I help maintain Yeah, they've got um ms They've got markdown rules linter that they use and say you make sure you do this don't do this Don't put multiple break lines in here multiple empty lines in this whole thing um I get it. I understand you want things to be consistent But that is can't be consistency within the project the one that I the thing that I uh, The one that I really don't like is when a vendor like what the share point framework team did when they start going in and putting in rules and from their own words They said if we think that we can do something to to improve or promote better coding practices, then we think that we should do it like Yeah, hold on a second now I get that there's some that you want to put in there and some of them Not very debatable not very in terms of like everyone's going to agree on this or eight out of 10 people are going to agree on it So I'll let that one. I'll let that one go But when you start telling me on how I should be on on how I should be doing developing my projects I may work for a large fortune 500 fortune 100 company and we have our own coding styles Who's to say that my coding styles our coding styles match what yours are Who's to say that i'm a fortune 500 that we're a bunch of developers that We aren't like it or or development is not a core Uh discipline at our organization. We're not a tech company. We're We sell sod Right, right and we have a little app that we wrote to do this I don't feel like you my rules my coding styles are going to be different than if I worked at google or microsoft or Or netflix and I don't think that a company like microsoft as a vendor Should be imposing those rules on my projects because now as somebody as a developer So this is firsthand as somebody as i'm using myself as an example It's somebody who writes typescript for everything. I use it for i use it for server side use it for client side I use it for share point framework projects use it for react projects that aren't share point framework. I use it for Teams projects that aren't share point framework I have a style that I like to follow And when it's only my stuff that i'm going to follow for all of my stuff But now when I create a new A new share point framework project someone in microsoft who doesn't write production code Yeah, right or who doesn't write like client facing code and they just write a tool to help me build my to write projects They now have come up someone arbitrarily decided that I should have the word public in front of all my constructors I'm like that's not necessary or now I can no longer use the private accessor on my On an argument in a constructor declaration. I'm like this is ridiculous This is not I think that to me that's overbearing and that's them overstepping their bounds And frankly if you want to go through the logical like to the real thing I get like when they say like Oh, if we can be doing something better to make our code better then we feel like we should do that I'm like, oh, well, let's make sure that everyone has full testing and you have code coverage being 100% on all of your projects Is that too far? I would say yes, but that's a different show But yeah, I guess the my point is Who's whose response is that their responsibility? And in my argument is no it's not their responsibility to find those rules I vendor for you giving me a tool to build new projects right as a framework Provider in this case as them playing the role of a framework provider where they expect organizations and individuals that cross the world as far as You know what their roles are what their you know Organizations are structured like whether they're selling a product creating an internal product Messing around because it's their saturday hobby whatever that is to provide a set of rules and say everybody has to abide by these rules I kind of I agree that I don't want that Enforced on me. I want that to be maybe a side thing an optional thing but I think The thing that even if it's forced on you right like even if you don't have an option when Structuring your project then I at the very very very least Want all of those rules to be at the top level. I think the thing that I dislike about the implementation most is that They're extending rule sets that exist in other projects so you end up with Two three or four depending on what project framework you pick you end up with three or four dependencies on other projects that have Lint rules defined in it. That's just a json string of key value pairs Essentially, I I want that up at that top level like if you're going to create me the es lint file For my configuration then put every single one of the rules that you wanted to find in that in that file so that I can Very quickly See what all the rules are make decisions. I think that's a good educational thing like if the point is that we're trying to in develop People with better coding practices then bring it front and center. Don't hide it. Don't hide it behind Buried node modules that you're you're bringing into your project and That's the part that kind of gets me the most. So I agree with you. I'd rather Maybe say, hey, I'm gonna have my own set of rules But now I'm doing this either deleting those, you know, I'm deleting a bunch of Dependencies and then restructuring the file. That's like a lot more steps that I got to go to to get my own You know version of the rules versus if you say No dependencies because you don't need any and you're just gonna in the project structure define An es lint config file with all of the rules spelled out that you are enforcing and make it super quick for people to go override that copy paste or replace the file entirely with one that you've got centrally located or you know, or just have a Maybe maybe you have a corporate Dependency that you're supposed to take that includes those files like why not that, you know what I'm saying Yes, that's the one and that's the part that I guess that I think that that's what irritates me about it is I just I feel that I feel like in this case here that it's a great example of Someone not really understanding how this how this works in the real world and how companies developers organizations product of isv's And just consumers of the project how this stuff is supposed to work I I gave a good example I gave example to somebody and I thought that this is this really sums up like my my two cents on the whole thing is that So when you have unit testing or automated testing you can have something in there that does code coverage And if you're if you if it will check things like functions branches statements All that kind of stuff and make sure that your code coverage is on a scale of one to one hundred in terms of a percentage of how much of your code is actually covered by automated tests And you can set a rule and you're testing to say that if your code coverage falls below these thresholds Then that's considered a red build Something broke the bill even if it works it's still a red build because you haven't put as much stuff in there Yeah, so from microsoft's point of view Do they want to go through and put testing inside of a default project cool? But they should not be putting any code coverage rules or any kind of numbers inside of it Maybe they can comment that section out, but they should put nothing in there when it comes to Uh like a utility that I have that that that updates a project to add that kind of testing in it I deliberately do not put in the code coverage rules in there I put in code coverage stuff in there to give you stats But I don't specify what the thresholds are for a green or a red build Right, but if I was if I if I was running a project like pmp.js I would have something like that in there code coverage in there because I want to make sure that someone is not Submitting a big pr and is putting no tests in there and they've dropped the level of our our coverage down because that means they're They're submitting code that is not This is not covered compared to the rest of it by tests Which if we said that there's a rule then we should enforce that so that's the part to me Like I thought that I think that those things kind of show that you can do it But you can do it in a way that doesn't feel like it's a big deal That or that's going to feel so overbearing these poor souls that go to use the share point framework And upgrade their project from 1.14 to 115 and now they're met with Literally, I heard this today One's guys got 555 warnings another guy's got 20 some odd errors and 970 warnings and they look at it go Is this a big deal? I'm like does it still work? And I guess it still works I'm like then you can turn off the as lint if you want and just keep going on with your project Is that a good idea? I'm like that's up to you But it's very intimidating. I think that's a problem like as a first-run experience Like so for you and a me that's used to using this stuff, you know, we like see that stuff and be like Jesus All right, fine. Let me go figure out which ones to shut down and you know, you you can work your way through it I think for other people they see that and they're like, I don't even know where to start Ah, ah, and I'm just going back to where I was You know, and I think that ends up being A little too intimidating is what I would fear, you know, I I could not agree more and I like I'm I'd be curious I you know look so we talked a little bit about the SharePoint framework stuff And I think that if you are a SharePoint framework developer, there's a few resources that we do want to provide you Um, I've posted a couple things. I'll post a couple things in the description for we've got I did a blog post in a video about it So if you want to see like what's the experience like and what and how do you go through and address the fixes in your Project for the common things that would show up. I gave you my two cents on that It's an opinion. That's a great resource Yeah, but it's a great resource to just get started if you feel if you're if this is happening to you Try one of the resources that are going to be Yes, that'll be the notes below and then the other one is that Uh, microsoft has said that they're interested in feedback. Um on this now they made this change And there is a discussion item on their issue list for the SharePoint framework Yeah, we'll do that in the show that people can go jump in and give them their two cents on it So if you want to have an impact on what on the decisions they've made Or decisions they make going forward, um You gotta give them you gotta be vocal, right? Yeah, if you it's like, you know If you don't give your representatives the feedback you don't get the government you want. Well, it's the same thing here So gotta vote gotta vote That's as far as political we're gonna go. Yeah, that's yes. We're done. That's that's it So hey, I know, you know, julie. This is the uh, is there anything else that you want to say on this? Or I know I think I think we really hit all the highlights. So So well one thing I do want to say is that I mean, this is the first or this is the last episode Of like a batch dump that we're doing with all these episodes. So we're this is the if you're if you get to this point Uh, you have probably seen uh that we released five episodes all at once Remember we did say that we're going to do about one a month or so at least that's the case We're going to start with so, uh, if you look at that's going bad There's like five of them. They just announced they got five right there I mean, I can't wait till the next episode like hold your horses We didn't want to just release like one episode and have you wait for 30 days for stuff. So we wanted to give you Yeah, we wanted to do show intro. So what is the show? And introducing you introducing me Uh, so people could know who we were and then two meat and potato episodes last episode Episode four was all about rest and the sdks in episode five. This one is all about linting Um, we will be coming back. We will be doing more episodes But again, we just wanted to set the expectations on where things would be and where we're uh, Please provide feedback if you have ideas for things you'd like us to cover Certainly put them in the comments of this episode or any of the episodes and we will be sure to see it Absolutely, absolutely. So And with with that with that I want to say hey, would you think about the episode right? So let us know by dropping a comment below Or submit a topic to discuss On future cloud dev clarity episodes And if you like this video, you like this episode Please give us a give us a thumbs up And smash that big red the sky button Before below the video that so that we'll see or you'll see when we publish new videos And new episodes on microsoft 365 and microsoft azure and related topics for developers. Thanks a lot. We'll see you in the next video