I agree with you. The reason for point 2 is to ask the question if it is possible at all. In theory, a successful implementation would not affect a good coder, but would provide pointers to a less than competent one. The assumption is that they learn over time. To be clear, this is in addition to code reviews. I suspect the answer is that such a system does not exist yet. Yes, the team already already uses static analysis and linters.
An example to me could be a tool that measures adherence to the SOLID principles, for example. While they don't necessarily apply completely to Go, they're a pretty good indicator of technical debt at the design level. On Saturday, June 8, 2019 at 4:01:40 AM UTC+12, jake...@gmail.com wrote: > > On Thursday, June 6, 2019 at 3:58:19 PM UTC-4, Carl wrote: >> >> I'd like to know what people are using to measure the quality of their Go >> code bases and why. Specifically, I'm asking if: >> >> 1. There is a way to score a code base on quality that works with >> idiomatic Go >> 2. Use this metric in a CI system and fail the build if the quality >> falls >> 3. Use this metric in a team to detect trends over time and hot spots >> where technical debt tends to accumulate >> >> It strikes me that Go is quite different to the usual set of popular >> languages and that even the most basic measures (cyclomatic complexity for >> example) may not be a good fit. >> >> For example: >> >> 1. Adding proper error handling increases measured complexity, but is >> actually preferable to not handling errors >> 2. A switch case where a case statement contains one or more commas >> is actually more maintainable, but would probably have the same score as >> individual case statements on separate lines >> >> There are already a lot of tools that analyse Go code in several >> different ways - but which ones really work in the long term? >> >> I'd like to ask the community which ones you've had good experiences with >> - a test of a good tool could be that a better score results in more >> idiomatic, maintainable code. >> > > I like https://github.com/golangci/golangci-lint for linting, it can give > you some ideas of stuff to look at. > > I don't know the reasons why you want such metrics, but I would strongly > caution against equating any automated metric with "code quality". > Personally, I would never choose to work somewhere where my code was judged > based on automated metrics. In my opinion, the only way to get good code is > to hire competent programmers, and require code reviews for all new code. > > Barring code because it fails some heuristic, seems like a recipe for > coders playing stupid tricks that makes good code bad, but also make it > pass the test. I have heard such stories in my decades coding. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dcf6d5de-b79e-4acf-9ccc-8bdb4eb562dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
