Thank you. That was very informative. On Tuesday, June 11, 2019 at 12:29:16 PM UTC+12, David Skinner wrote: > > 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. > > On Thursday, June 6, 2019 at 2:58:19 PM UTC-5, 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. >> >
-- 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/f939b63b-0619-47c0-a5ce-418a50aac934%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
