🆘 NEED HELP? 🆘 Book a 1:1 Consultation with CoderDave: geni.us/cdconsult We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with! 🙏🏻SUPPORT THE CHANNEL🙏🏻 Buy me a coffee: www.buymeacoffee.com/CoderDave PayPal me donation: paypal.me/dabenveg
Yeah I would hope most teams use a linter of some sort already, if only to use while writing the code. The Visual Studio Code list of extensions included several dozen highly recommended linters. I don't code as much as I used to so I don't know which ones are the most popular / best at this time.
Hi. Thanks for your efforts. Just a comment - linters can't find bugs. They can't understand what logic is right. The don't analysis logic, they do code analysis. It may point to code which *may* cause a bug
Well the list would be too long, because it depends on the language. However, with VSCode the best thing to do is seeing in the Extentions list which ones have the most stars ;)
Yeah .. but linters do none of those things and/or are just plain redundant. In fact they make it worse in many cases. Team, and individual discipline produces high quality code, not linters. On the other hand, if we have nothing to do we pick it up and write a blog post on it so our competition can pick it up.
I am not sure why you are saying that linters don't do what I mentioned in the video... nor why you think they make things worse. Ah right, perhaps millions of people using linters are wrong. That makes more sense
@@CoderDave I am saying that because I used them. There where millions of people burning women who had no kids and too many cats. So .. your argument is as invalid as invalid can get. But I am sure you are here for my arguments. First, there are some excellent tools which pick up, for example, unnecessary memory operations, duplicate code segments, etc.. which does remove some cognitive load and actually could make the codebase a bit better, provided there are no generalisation maniacs of your team. Any error detection that a linter may have is just simply incapable to detect anything more than glaringly obvious errors. Glaringly obvious errors get usually picked up by team members during the review meetings or pair programming sessions immediately. The visibility of deep nested errors, on the other hand, are an indicative of bad application architecture and few, if no linter will pick those up. Or .. legacy code, but rarely. Code readability and general conventions was never an issue. I have not yet met a developer who does not spend some minimum amount of time on making his code readable. And... I have yet to meet one which does unreadable code due to the style he uses. Tabs and spaces questions are retardedly simple and should not require a liner. Further, i like to keep a rhythm in my code. Broken 'if' statements, as another example, are not exactly readable. Security is a built in feature of every app (or it should be) ever created. That being said. The final nail in the coffin of linters comes from the general adoption workflow of it: Your team installs it, agrees on some general rules, spends 2-3 months battling and tweaking those rules, obviously increasing lead times, and after a while ... it becomes invisible. Everybody adapts and does perfectly conforming code. And therein lies the uselessness of linters in general. The linter does nothing anymore besides increasing deployment times and costs. Workflow for adaptive conformity involves a bit of back and forth at the integration stage. Which at the end produces much better results much faster which everyone enjoys to at least to some degree. Especially fast if you integrate changes 3-4 times a week. For newcomers to the team, I found it much easier to spend some time with them and explain how things are going around the team and ask for input. There has been multiple times I changed style, project patterns and even workflow because of the insights of a junior or a mid level new to the team. You can't do that easily with a linter in place and sure as hell fuck up if you rely on it exclusively (ask me how i know).
in first 1 min one should be able to explain any concept in the most simplest manner...like teaching to a 5yr old....else it will be very tough to grow a channel which teaches complex things............
🆘 NEED HELP? 🆘
Book a 1:1 Consultation with CoderDave: geni.us/cdconsult
We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with!
🙏🏻SUPPORT THE CHANNEL🙏🏻
Buy me a coffee: www.buymeacoffee.com/CoderDave
PayPal me donation: paypal.me/dabenveg
Yeah I would hope most teams use a linter of some sort already, if only to use while writing the code. The Visual Studio Code list of extensions included several dozen highly recommended linters. I don't code as much as I used to so I don't know which ones are the most popular / best at this time.
Couldn't agree more! Unfortunately not many teams do, at least in my experience
Is Linter required when a SCA tool like Coverity is already being used?
It’s never required, but it’s definitely good to have 😀
Amazing introduction video on linters, thank you for the information!
Glad it was helpful! :)
The explanation was perfect. Thank you so much for that!
Glad it was helpful!
Woww ! It was so informative & easily understanding. Thanks for helping us.
Glad it was helpful!
Hi. Thanks for your efforts. Just a comment - linters can't find bugs. They can't understand what logic is right. The don't analysis logic, they do code analysis. It may point to code which *may* cause a bug
Good point!
Great stuff, Buddy! Thank you.
Great to know it's helpful :)
Thank you. Very straightforward
Happy you liked it ☺️
Short & Sweet ...
Hehe 😉
Can u suggest the name of the best linters for VS code
Well the list would be too long, because it depends on the language. However, with VSCode the best thing to do is seeing in the Extentions list which ones have the most stars ;)
wonderful video. Thanks!
thanks!
Thanks, Great Video
Happy you found it helpful
Most informative video
Glad you think so!
thank you dave
You’re welcome 😀
Really good video my man.
Glad you enjoyed it!
Thx for the super clear explaination.. :)
Glad it was helpful!
thsmks that was good
Glad you liked it :)
Great explanation 👏👏👏
Thanks! Happy to know you liked it ☺️
Thank you, sir
Most welcome
nice one
Thanks
thanks
You're welcome!
I enjoyed it
Thanks! What did you like of the video?
@@CoderDave the presentation and the content.. generally its put more context into the meaning of static code analysis and linters.
Which theme is this
Do you mean the VSCode theme? I think it’s just the default dark one… I’ve never installed any additional theme 😄
Yeah .. but linters do none of those things and/or are just plain redundant. In fact they make it worse in many cases. Team, and individual discipline produces high quality code, not linters.
On the other hand, if we have nothing to do we pick it up and write a blog post on it so our competition can pick it up.
I am not sure why you are saying that linters don't do what I mentioned in the video... nor why you think they make things worse. Ah right, perhaps millions of people using linters are wrong. That makes more sense
@@CoderDave I am saying that because I used them.
There where millions of people burning women who had no kids and too many cats. So .. your argument is as invalid as invalid can get. But I am sure you are here for my arguments.
First, there are some excellent tools which pick up, for example, unnecessary memory operations, duplicate code segments, etc.. which does remove some cognitive load and actually could make the codebase a bit better, provided there are no generalisation maniacs of your team.
Any error detection that a linter may have is just simply incapable to detect anything more than glaringly obvious errors. Glaringly obvious errors get usually picked up by team members during the review meetings or pair programming sessions immediately. The visibility of deep nested errors, on the other hand, are an indicative of bad application architecture and few, if no linter will pick those up. Or .. legacy code, but rarely.
Code readability and general conventions was never an issue. I have not yet met a developer who does not spend some minimum amount of time on making his code readable. And... I have yet to meet one which does unreadable code due to the style he uses. Tabs and spaces questions are retardedly simple and should not require a liner. Further, i like to keep a rhythm in my code. Broken 'if' statements, as another example, are not exactly readable.
Security is a built in feature of every app (or it should be) ever created.
That being said. The final nail in the coffin of linters comes from the general adoption workflow of it: Your team installs it, agrees on some general rules, spends 2-3 months battling and tweaking those rules, obviously increasing lead times, and after a while ... it becomes invisible. Everybody adapts and does perfectly conforming code. And therein lies the uselessness of linters in general. The linter does nothing anymore besides increasing deployment times and costs.
Workflow for adaptive conformity involves a bit of back and forth at the integration stage. Which at the end produces much better results much faster which everyone enjoys to at least to some degree. Especially fast if you integrate changes 3-4 times a week.
For newcomers to the team, I found it much easier to spend some time with them and explain how things are going around the team and ask for input. There has been multiple times I changed style, project patterns and even workflow because of the insights of a junior or a mid level new to the team. You can't do that easily with a linter in place and sure as hell fuck up if you rely on it exclusively (ask me how i know).
in first 1 min one should be able to explain any concept in the most simplest manner...like teaching to a 5yr old....else it will be very tough to grow a channel which teaches complex things............
boring content without graphics explanation
Sorry you feel that way