refactor(customize): improve code readability #1412

@@ Coverage Diff @@
## master #1412 +/- ##
==========================================
+ Coverage 97.33% 97.59% +0.25% 
==========================================
 Files 42 57 +15 
 Lines 2104 2657 +553 
==========================================
+ Hits 2048 2593 +545 
- Misses 56 64 +8

Flag	Coverage Δ
unittests	`97.59% <100.00%> (+0.25%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@bearomorphism bearomorphism force-pushed the refactor-customize branch from 39792a0 to ce36db5 Compare

May 15, 2025 01:30

@bearomorphism

Copy link

Contributor Author

bearomorphism commented May 15, 2025 •

edited

Loading

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

https://chatgpt.com/share/68254494-f83c-8010-8ab3-7f8808682bcf

probably not important

noirbizarre

noirbizarre reviewed

May 15, 2025

View reviewed changes

commitizen/cz/customize/customize.py Show resolved Hide resolved

commitizen/cz/customize/customize.py Outdated Show resolved Hide resolved

commitizen/cz/customize/customize.py Show resolved Hide resolved

@noirbizarre

Copy link

Member

noirbizarre commented May 15, 2025

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

Actually, it matters: if you have some_key: in your settings, meaning empty key in yaml, the key exists and the first one returns None while the second one returns "".
The second approach is most of the time safer is it ensure all falsy values will and with the same type:

yaml	`.get("key", "")`	`.get("key") or ""`
Not set	`""`	`""`
`key: ""`	`""`	`""`
`key:`	`None`	`""`
`key: false`	`False`	`""`
`key: 0`	`0`	`""`
`key: []`	`[]`	`""`
`key: {}`	`{}`	`""`
`key: no` (yaml 1.1)	`False`	`""`

So it really depends on your case, but if there is no default value, and you want to be sure of the type you have in case of falsy value, go for the 2nd.

@bearomorphism


 refactor(customize): improve code readability

e163049

@bearomorphism bearomorphism force-pushed the refactor-customize branch from ce36db5 to e163049 Compare

May 15, 2025 11:47

@bearomorphism

Copy link

Contributor Author

bearomorphism commented May 15, 2025 •

edited

Loading

I was curious about the difference between .get("some_key", "") and .get("some_key") or ""

Actually, it matters: if you have some_key: in your settings, meaning empty key in yaml, the key exists and the first one returns None while the second one returns "". The second approach is most of the time safer is it ensure all falsy values will and with the same type:

yaml .get("key", "") .get("key") or ""
Not set "" ""
key: "" "" ""
key: None ""
key: false False ""
key: 0 0 ""
key: [] [] ""
key: {} {} ""
key: no (yaml 1.1) False ""
So it really depends on your case, but if there is no default value, and you want to be sure of the type you have in case of falsy value, go for the 2nd.

Thank you for explanation. Actually, the thing I'm not sure is if we want to fallback to empty string if the value is falsy (current implementation).

@noirbizarre

Copy link

Member

noirbizarre commented May 15, 2025 •

edited

Loading

I think this has been a recurrent discussion on reviews: we have some improvements to do on the "cli flags > user settings > default value" cascading handling:

lots of repetitions
sometimes we have the same setting with different behavior depending on the command
...

There is room for improvement.
But we have to maintain backward compatibility, so the day we change that, it might be a breaking change.

@Lee-W

Copy link

Member

Lee-W commented May 16, 2025

I think this has been a recurrent discussion on reviews: we have some improvements to do on the "cli flags > user settings > default value" cascading handling:
* lots of repetitions
* sometimes we have the same setting with different behavior depending on the command
* ...
There is room for improvement. But we have to maintain backward compatibility, so the day we change that, it might be a breaking change.

I've also wanted to rewrite the whole setting, default value thing....

@bearomorphism

Copy link

Contributor Author

bearomorphism commented May 20, 2025

I think this has been a recurrent discussion on reviews: we have some improvements to do on the "cli flags > user settings > default value" cascading handling:
* lots of repetitions
* sometimes we have the same setting with different behavior depending on the command
* ...
There is room for improvement. But we have to maintain backward compatibility, so the day we change that, it might be a breaking change.
I've also wanted to rewrite the whole setting, default value thing....

I can try this. We can discuss when you have time.