Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code formatting #136

Closed
danielRi opened this issue Sep 29, 2023 · 2 comments
Closed

Code formatting #136

danielRi opened this issue Sep 29, 2023 · 2 comments

Comments

@danielRi
Copy link

Hi,

I´m using fpdart in an enterprise project and along its usefulness I´m also having a great time using it.

One thing that just bothers me a little bit is the dart code formatter often formats the code in a way that makes the code not as readable as it actually is, e.G. when nesting multiple .maps .folds etc... and inside these function there are lots of calls again.

Does anyone has the same experience or noticed this problem? Im not sure how to solve it, thought maybe the fpdart team has some tips to this?

@zellidev0
Copy link
Contributor

I assume this is not a specific fpdart problem.
The code style is defined by the official dart linter rules which are used in the recommended (package:lints/recommended.yaml) manner in the project.

But I know there are times that make the code harder to read just because of the formatting.

One tip I can give you is to use the Do() constructor when nesting multiple maps (flapmapping etc.). But beware of the downsides mentioned here.

You can also use teardown functions if possible to make the code shorter in some cases or use the _ identifier when naming a variable. This also makes the explicit type annotation not enforced, when using the specific linter rule.

@SandroMaglione
Copy link
Owner

@danielRi as @zellidev0 mentioned this is related to how dart itself formats the code.

There is a proposal for updating how formatting and trailing commas work.

For now you can either add commas where needed to format the code, or another option would be to use the Do notation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants