A good indicator of code quality

[Carl]

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.

[Robert Johnstone]

You can look at https://goreportcard.com/ to get a look at some common metrics.  There are also quite a few different linters (golint, revive, staticcheck, plus others).

Robert

[andrey mirtchovski]

"does it look like the go standard library?"

that style is desirable, yet inimitable

[jake...@gmail.com]

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.

 

[Michael Ellis]

On Friday, June 7, 2019 at 12:01:40 PM UTC-4, jake...@gmail.com wrote:

I don't know the reasons why you want such metrics, but I would strongly caution against equating any automated metric with "code quality". 

Amen. To my mind the most useful metric is what a mentor of mine dubbed "maximum locality". He explained it this way: Go into a programmers cubicle and look through the little stickies on the wall that represent fixes and features to be added.  The quality of the code is the extent to which all of them can be implemented by changing one place in one file.

I have no idea how you'd ever automate that, at least not prospectively.

[Carl]

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.

[David Skinner]

Back in 1988, I was tasked with a code review for what seems like 150 programmers. Now I am very lazy, being a good programmer, I am willing to spend all day automating a one hour job. They were all using an in house OOPS language. I performed a cluster analysis of metrics using a Comal program augmented with C packages (tool set I used as actuary). What I discovered at that time is that most of the programmers metrics were in a centroid cluster of characteristics and a very few were outliers. The problems seemed to be in two groups, spaghetti code written by people who cut and paste without comprehension and those unable to create useful abstractions and created a plethora of classes and functions. Some of the programmers had to be moved to QA, some of the programmers got pay raises and stock options.

With Go, all of our code reviews are manual, the very nature of the language promotes the development of useful orthogonal abstractions.

If you are working with a large group of programmers, I do believe in using heuristics, but be aware of its limitations, the Heisenberg Uncertainty Principle says that you cannot measure something without changing it, if it is known that you are measuring something then that measurement becomes useless.

I do believe in a 5% to 10% duplication of effort. I will give the same assignment to two different programmers, see who does the best job in the least time. Best job does tend to be rather subjective. Least time is easy, matter of time sheets. Least time is dangerous, i prefer a meticulous programmer with complete documentation and a bug free proven product, but is someone can do a quality job faster, you best measure it and compensate so you do not lose that person..

I wish you the best of luck but keep in mind that not everyone writes idiomatic Go, most programmers will have a prior history with other languages that may impact how they code. Poorly designed heuristics may penalize good programmers for not doing things in an inferior way.

[Rob Pike]

"[T]he Heisenberg Uncertainty Principle says that you cannot measure something without changing it". Actually no, that is the Observer Paradox. The Heisenberg Uncertainty Principle states that the product of the uncertainty of complementary variables, such as momentum and position, can never be less than h/4pi. It is a very different statement.

The observer paradox applies to your situation, though.

-rob

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/73fafe92-8cb5-4c69-b16d-ede473bfeb16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[carl.menez...@gmail.com]

Thank you. That was very informative.