URIs should not be hardcoded

What it does

Hard-coded URIs can lead to several disadvantages in software development:

• Lack of Flexibility: Changing a hard-coded URI requires modifying the source code and redeploying the application, which can be cumbersome and time-consuming.

• Maintainability Issues: As applications grow, managing multiple hard-coded URIs becomes difficult. It increases the risk of introducing errors when making changes.

• Environment Configuration Challenges: Hard-coded URIs can hinder the ability to easily switch between environments (e.g., development, testing, production) without changing the code.

• Security Risks: Exposing sensitive URIs in the source code can lead to security vulnerabilities, such as unauthorized access to APIs or services.

• Version Control Issues: Hard-coded values can make it difficult to track changes over time, complicating version control and audit trails.

• Code Readability: Hard-coded URIs can clutter the code and make it harder to understand, especially if the URI is long or complex.

• Testing Difficulties: Testing different environments or endpoints becomes cumbersome if URIs are hard-coded, as it may require recompilation for every change.

• Reduced Reusability: Functions or modules with hard-coded URIs are less reusable since they are tied to specific services or endpoints.

Advantage

• mitigate the issues mentioned in the description

Drawbacks

No response

Example

use reqwest::blocking::get;
use reqwest::Error;

// Noncompliant
const API_URL: &str = "http://example.com/api";

fn fetch_api_data() -> Result<String, Error> {
    let response = get(API_URL)?;
    response.text()
}

The issue provides a Rust example using reqwest and a hard-coded API_URL, but names no source files, tests, or existing lint entry point. First clarify which URI patterns and configuration mechanisms are in scope, then inspect existing Clippy lint conventions. Done should include an agreed detection scope and tests demonstrating the intended behavior.