Code reviews are necessary to ensure your application is consistent. We live in an age of copy-and-paste craftsmen, so making sure that the bits th...
For further actions, you may consider blocking this person and/or reporting abuse
A linter to check code duplication would be awesome! Do you know of any?
We all know, there are only two hard things in Computer Science: cache invalidation and naming things. That's why I check naming, even if it is entirely subjective.
Focusing on architectural/design issues at a code review is a little late for me, those should be ironed out at planning, however they should be raised at this stage if that did not occur. Thanks for the comment, I'll add in a section for it.
To add to Aleksei's list, we use Sonarqube to catch everything you mentioned for Java, Javascript, TypeScript, and C#. There are plenty of other plugins that expand Sonarqube's language support, too.
sonarqube.org/
We use Teamscale for this purpose, as it is much faster and independent from the build.
teamscale.com
Thanks Dan, Looks good. There are so many different tools! Picking one is always a conundrum.
We use codegrip.tech, its automated, supports more than 20+ languages and more importantly has great UI and integrations with slack. Price is very low compare to different tools present in market.
Nice, thanks for the introduction. Will take a look.
i'd definitely double underline the caution in the Code Duplication item. i've seen dry turn pathological.
pushing or encouraging deduping too strongly leads you away from small, simple changes--hey i copied a line from one service into another--and into a cascading cluster of refactoring and renaming and rethinking--hey... so i spent the last week completely redesigning the system and now every basic equality check or destructuring statement is separated out into one of a dozen "helper" files and each concrete step of each procedure is abstracted away behind at least three levels of indirection, but hey at least we aren't repeating ourselves!
i'd rather get the functionality in first and then start a second, new task looking into that possible deduping. sometimes it makes sense, and sometimes you're just making contrived abstractions that will hurt to maintain later.
Thanks for the comment, I completely agree and have amended the article. People love to refactor once a feature is complete. That basically negates the benefits, unless you know that this is going to be touched again shortly!
P.S - Underlines are not supported in Markdown, let also double underlines! But I've chucked it in a blockquote! 😁
You can automate most of these stuff with a linter in your commit/PR to master pipeline, and treat warnings as build errors.
Thank you, really nice article where you have brought together years of expertise.
Thanks, Pronto looks great, will give it a try.