func runMachineClone
has a cyclomatic complexity of 41 with "very-high" risk 83 return cmd
84}
85
86func runMachineClone(ctx context.Context) (err error) { 87 var (
88 out = iostreams.FromContext(ctx).Out
89 appName = appconfig.NameFromContext(ctx)
func ToTestMachineConfig
has a cyclomatic complexity of 16 with "high" risk 91 }
92}
93
94func (c *Config) ToTestMachineConfig(svc *ServiceMachineCheck, origMachine *fly.Machine) (*fly.MachineConfig, error) { 95 var machineEntrypoint []string
96 if svc.Entrypoint != nil {
97 machineEntrypoint = svc.Entrypoint
func updateMachineConfig
has a cyclomatic complexity of 21 with "high" risk217}
218
219// updateMachineConfig applies configuration options from the optional MachineConfig passed in, then the base config, into a new MachineConfig
220func (c *Config) updateMachineConfig(src *fly.MachineConfig) (*fly.MachineConfig, error) {221 // For flattened app configs there is only one proces name and it is the group it was flattened for
222 processGroup := c.DefaultProcessName()
223
func warnAboutIncorrectListenAddress
has a cyclomatic complexity of 18 with "high" risk 949 fmt.Fprint(md.io.Out, "\n")
950}
951
952func (md *machineDeployment) warnAboutIncorrectListenAddress(ctx context.Context, lm machine.LeasableMachine) { 953 group := lm.Machine().ProcessGroup()
954
955 if _, seen := md.listenAddressChecked.LoadOrStore(group, struct{}{}); seen {
func deployToMachines
has a cyclomatic complexity of 19 with "high" risk339}
340
341// in a rare twist, the guest param takes precedence over CLI flags!
342func deployToMachines(343 ctx context.Context,
344 cfg *appconfig.Config,
345 app *fly.AppCompact,
A function with high cyclomatic complexity can be hard to understand and maintain. Cyclomatic complexity is a software metric that measures the number of independent paths through a function. A higher cyclomatic complexity indicates that the function has more decision points and is more complex.
Functions with high cyclomatic complexity are more likely to have bugs and be harder to test. They may lead to reduced code maintainability and increased development time.
To reduce the cyclomatic complexity of a function, you can:
package main
import "log"
func fizzbuzzfuzz(x int) { // cc = 1
if x == 0 || x < 0 { // cc = 3 (if, ||)
return
}
for i := 1; i <= x; i++ { // cc = 4 (for)
switch i % 15 * 2 {
case 0: // cc = 5 (case)
countDiv3 += 1
countDiv5 += 1
log.Println("fizzbuzz")
break
case 3:
case 6:
case 9:
case 12: // cc = 9 (case)
countDiv3 += 1
log.Println("fizz")
break
case 5:
case 10: // cc = 11 (case)
countDiv5 += 1
log.Println("buzz")
break
default:
log.Printf("%d\n", x)
}
}
} // CC == 11; raises issues
package main
import "log"
func fizzbuzz(x int) { // cc = 1
for i := 1; i <= x; i++ { // cc = 2 (for)
y := i%3 == 0
z := i%5 == 0
if y == z { // 3
if y == false { // 4
log.Printf("%d\n", i)
} else {
log.Println("fizzbuzz")
}
} else {
if y { // 5
log.Println("fizz")
} else {
log.Println("buzz")
}
}
}
} // CC == 5
Cyclomatic complexity threshold can be configured using the
cyclomatic_complexity_threshold
(docs) in the
.deepsource.toml
config file.
Configuring this is optional. If you don't provide a value, the Analyzer will
raise issues for functions with complexity higher than the default threshold,
which is medium
(only raise issues for >15) for the Go Analyzer.
Here's the mapping of the risk category to the cyclomatic complexity score to help you configure this better:
Risk category | Cyclomatic complexity range | Recommended action |
---|---|---|
low | 1-5 | No action needed. |
medium | 6-15 | Review and monitor. |
high | 16-25 | Review and refactor. Recommended to add comments if the function is absolutely needed to be kept as it is. |
very-high. | 26-50 | Refactor to reduce the complexity. |
critical | >50 | Must refactor this. This can make the code untestable and very difficult to understand. |