The config_create() function in src/shared/config.c (line 12) takes 11 positional parameters — a mix of char*, bool, and int. At the call site in client_cli.c:77-78, the argument list spans two lines and is nearly impossible to read correctly without counting parameters:
This is fragile: adding a new field reorders or shifts all subsequent arguments, and nothing prevents the wrong false/NULL from being passed in the wrong slot. Every time a new field is added to the Config struct, this constructor signature must change.
A better approach would be:
Use a zero-initialized struct literal + setters, or
Adopt a builder pattern, or
Use designated initializers with a Config initializer macro.
Location
src/shared/config.c:12-57 and src/client/client_cli.c:77-78
Suggested Fix
Replace the 11-parameter constructor with:
A Config* config_create_default(void) that returns a config with all defaults.
Individual setter functions or direct field assignment with documented defaults.
Or a macro: #define CONFIG_INIT { .version = str_dup(PROTOCOL_VERSION), .compression_level = 5, ... }
This eliminates the risk of parameter misordering and makes call sites self-documenting.
Severity
Medium
Category
Quality / Maintainability
## Description
The `config_create()` function in `src/shared/config.c` (line 12) takes **11 positional parameters** — a mix of `char*`, `bool`, and `int`. At the call site in `client_cli.c:77-78`, the argument list spans two lines and is nearly impossible to read correctly without counting parameters:
```c
Config* config = config_create(str_dup(PROTOCOL_VERSION), NULL, NULL, save_to_disk, false, false,
false, false, 5, false, 0);
```
This is fragile: adding a new field reorders or shifts all subsequent arguments, and nothing prevents the wrong `false`/`NULL` from being passed in the wrong slot. Every time a new field is added to the `Config` struct, this constructor signature must change.
A better approach would be:
1. Use a zero-initialized struct literal + setters, or
2. Adopt a builder pattern, or
3. Use designated initializers with a `Config` initializer macro.
## Location
`src/shared/config.c:12-57` and `src/client/client_cli.c:77-78`
## Suggested Fix
Replace the 11-parameter constructor with:
- A `Config* config_create_default(void)` that returns a config with all defaults.
- Individual setter functions or direct field assignment with documented defaults.
- Or a macro: `#define CONFIG_INIT { .version = str_dup(PROTOCOL_VERSION), .compression_level = 5, ... }`
This eliminates the risk of parameter misordering and makes call sites self-documenting.
## Severity
Medium
## Category
Quality / Maintainability
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
The
config_create()function insrc/shared/config.c(line 12) takes 11 positional parameters — a mix ofchar*,bool, andint. At the call site inclient_cli.c:77-78, the argument list spans two lines and is nearly impossible to read correctly without counting parameters:This is fragile: adding a new field reorders or shifts all subsequent arguments, and nothing prevents the wrong
false/NULLfrom being passed in the wrong slot. Every time a new field is added to theConfigstruct, this constructor signature must change.A better approach would be:
Configinitializer macro.Location
src/shared/config.c:12-57andsrc/client/client_cli.c:77-78Suggested Fix
Replace the 11-parameter constructor with:
Config* config_create_default(void)that returns a config with all defaults.#define CONFIG_INIT { .version = str_dup(PROTOCOL_VERSION), .compression_level = 5, ... }This eliminates the risk of parameter misordering and makes call sites self-documenting.
Severity
Medium
Category
Quality / Maintainability