refactor(customize): improve code readability

[bearomorphism]

Description

Make the code shorter but still easy to read.

Checklist

• Add test cases to all the changes you introduce
• Run poetry all locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

NA, this is refactor.

Steps to Test This Pull Request

Additional context

NA

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.59%. Comparing base (120d514) to head (e163049).
Report is 621 commits behind head on master.

Additional details and impacted files

@@ 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]

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]

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]

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: falseFalse""
key: 00""
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]

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]

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]

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.

[Lee-W]

Created an issue #1445 to track and discuss this redesign, probably will go to v5