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

feat(deriv_lint): update lint rules #587

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ahrar-deriv
Copy link
Contributor

@ahrar-deriv ahrar-deriv commented May 16, 2024

Clickup link: https://app.clickup.com/t/20696747/DERG-2271

This PR contains the following changes:

  • updated to the latest researched lint rules
  • ✨ New feature (non-breaking change which adds functionality)
  • 🛠️ Bug fix (non-breaking change which fixes an issue)
  • ❌ Breaking change (fix or feature that would cause existing functionality to change)
  • 🧹 Code refactor
  • ✅ Build configuration change
  • 📝 Documentation
  • 🗑️ Chore

Developers Note (Optional)

Pre-launch Checklist (For PR creator)

As a creator of this PR:

  • ✍️ I have included clickup id and package/app_name in the PR title.
  • 👁️ I have gone through the code and removed any temporary changes (commented lines, prints, debug statements etc.).
  • ⚒️ I have fixed any errors/warnings shown by the analyzer/linter.
  • 📝 I have added documentation, comments and logging wherever required.
  • 🧪 I have added necessary tests for these changes.
  • 🔎 I have ensured all existing tests are passing.

Reviewers

@sahani-deriv @ramin-deriv @abedelaziz-deriv

Pre-launch Checklist (For Reviewers)

As a reviewer I ensure that:

  • ✴️ This PR follows the standard PR template.
  • 🪩 The information in this PR properly reflects the code changes.
  • 🧪 All the necessary tests for this PR's are passing.

Pre-launch Checklist (For QA)

  • 👌 It passes the acceptance criteria.

Pre-launch Checklist (For Maintainer)

  • [MAINTAINER_NAME] I make sure this PR fulfills its purpose.

@ahrar-deriv ahrar-deriv changed the title feat: update lint rules feat(deriv_lint): update lint rules May 16, 2024
- null_closures
- omit_local_variable_types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this conflicts with always specify type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think so , the omit_local_variable_types is just for local variable . but the always specify is for outside the scope vars

- always_put_required_named_parameters_first
- always_require_non_null_named_parameters
- always_specify_types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a great rule for code readability

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Details
#
NOTE: This rule is removed in Dart 3.3.0; it is no longer functional.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is about always_specify_types @ahrar-deriv . Is there a reason to remove it?

- use_function_type_syntax_for_parameters
- use_if_null_to_convert_nulls_to_bools
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't you think it is cleaner the other way around?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@ahrar-deriv ahrar-deriv May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the base for our projects. if any rule does not make sense to the team they can
alter it like this

rules:
       use_if_null_to_convert_nulls_to_bools: false

overall I think it is good that we are doing it in null-aware fashion

Copy link
Contributor

@abedelaziz-deriv abedelaziz-deriv May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the link. I know it is effective dart, but do you think it is cleaner to assign a value instead of == true/false?
Their rules can change from bad to good overnight, it is up to us to decide what is best :D

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes all are subjective. we can vote on it :) all the rules are here for debate

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

Successfully merging this pull request may close these issues.

2 participants