fn _on_error
has a cyclomatic complexity of 44 with "very-high" risk 25 Error,
26};
27
28async fn _on_error(error: FrameworkError<'_, Data, Error>) { 29 info!("handling error event");
30 #[allow(unreachable_patterns)]
31 match error {
fn connect_to_vc
has a cyclomatic complexity of 29 with "very-high" risk 13
14// TODO: implement `force`
15#[allow(clippy::let_unit_value)]
16pub async fn connect_to_vc( 17 ctx: Context,
18 guild_id: GuildId,
19 channel_id: ChannelId,
fn join
has a cyclomatic complexity of 48 with "very-high" risk 14/// Join a voice chat.
15/// Transcripts will be logged to the channel you run this command in.
16#[poise::command(prefix_command, slash_command, guild_cooldown = 15, check = "is_guild")]
17pub async fn join( 18 ctx: Context<'_>,
19 #[description = "Voice chat to bind to. Defaults to the one you're in."]
20 #[channel_types("Voice", "Stage")]
fn handle_silent_speakers
has a cyclomatic complexity of 27 with "very-high" risk132 kiai_client: KiaiApiClient,
133 voice_channel_id: ChannelId,
134}
135async fn handle_silent_speakers<'a>(136 SilentSpeakersContext {
137 ssrc_state,
138 last_tick_speakers,
fn stripe_webhook
has a cyclomatic complexity of 37 with "very-high" risk 13 },
14};
15
16pub async fn stripe_webhook( 17 Authentication {
18 user_id: auth_user_id,
19 ..
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:
use anyhow::{anyhow, Context, Result};
use std::io::{Lines, StdinLock};
trait InputHandle {
type Input<'a>
where
Self: 'a;
fn get_input<'a>(&self) -> Self::Input<'a>;
fn process_input<'a, T>(&self, f: impl FnOnce(Self::Input<'a>) -> Result<T>) -> Result<T>
where
Self: 'a;
}
struct StdioInput;
impl InputHandle for StdioInput {
type Input<'a> = Lines<StdinLock<'a>>;
fn get_input<'a>(&self) -> Self::Input<'a> {
std::io::stdin().lines()
}
fn process_input<'a, T>(&self, f: impl FnOnce(Self::Input<'a>) -> Result<T>) -> Result<T>
where
Self: 'a,
{
f(self.get_input())
}
}
fn main() -> Result<()> {
// cc = 1 (default)
let index: usize = StdioInput.process_input(|mut input| {
// cc = 3 (?, ?)
str::parse(input.next().context("no input from stdin")??.as_str()).context("parse failed")
})?; // cc = 4 (?)
// cc = 5 (for)
for i in 0..index {
let fizzbuzz = match i % 15 {
// cc = 6 (match_arm 0)
0 => "fizzbuzz".into(),
// cc = 9 (match_arm 3 | 6 | 9)
3 | 6 | 9 | 12 => "fizz".into(),
// cc = 11 (match_arm 5 | 10)
5 | 10 => "buzz".into(),
x => format!("{x}"),
};
println!("{i}: {fizzbuzz}");
}
Ok(())
}
use anyhow::{anyhow, Context, Result};
use std::io::{Lines, StdinLock};
trait InputHandle {
type Input<'a>
where
Self: 'a;
fn get_input<'a>(&self) -> Self::Input<'a>;
fn process_input<'a, T>(&self, f: impl FnOnce(Self::Input<'a>) -> Result<T>) -> Result<T>
where
Self: 'a;
}
struct StdioInput;
impl InputHandle for StdioInput {
type Input<'a> = Lines<StdinLock<'a>>;
fn get_input<'a>(&self) -> Self::Input<'a> {
std::io::stdin().lines()
}
fn process_input<'a, T>(&self, f: impl FnOnce(Self::Input<'a>) -> Result<T>) -> Result<T>
where
Self: 'a,
{
f(self.get_input())
}
}
fn fizzbuzz(u: usize) -> String {
// cc = 1 (default)
match u % 15 {
// cc = 2 (match_arm 0)
0 => "fizzbuzz".into(),
// cc = 9 (match_arm 3 | 6 | 9)
3 | 6 | 9 | 12 => "fizz".into(),
// cc = 11 (match_arm 5 | 10)
5 | 10 => "buzz".into(),
x => format!("{x}"),
}
} // total cc =
fn main() -> Result<()> {
// cc = 1 (default)
let index: usize = StdioInput.process_input(|mut input| {
// cc = 3 (?, ?)
str::parse(input.next().context("no input from stdin")??.as_str()).context("parse failed")
})?; // cc = 4 (?)
// cc = 5 (for)
for i in 0..index {
let val = fizzbuzz(i);
println!("{i}: {val}");
}
Ok(())
}
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 high
(only raise issues for >25) for the Rust 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. |