Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
A personal preferences for a starting point for my Dart & Flutter linter rules.
# Include and activate all lint rules, later below we disable the not used or desired ones.
include: all_lint_rules.yaml
analyzer:
exclude:
- "**/*.g.dart"
- "**/*.freezed.dart"
strong-mode:
implicit-casts: false
implicit-dynamic: false
errors:
# Otherwise we cause the import of all_lint_rules to warn, because of some rules conflicts.
# We explicitly enabled even conflicting rules and are fixing the conflicts in this file.
included_file_warning: ignore
# Treat missing required parameters as an error, not as a hint or a warning.
missing_required_param: error
# Treat missing returns as an error, not as a hint or a warning.
missing_return: error
# Allow having TODOs in the code.
todo: ignore
# Causes false positives (https://github.com/dart-lang/sdk/issues/41571
top_level_function_literal_block: ignore
# DON'T assign new values to parameters of methods or functions.
#
# https://dart-lang.github.io/linter/lints/parameter_assignments.html
#
# Treat assigning new values to a parameter as a warning. I would almost like to set this
# to an error. However, this warning rule or even more so if set to an error, can sometimes
# be a bit problematic you include other code directly that does it a lot.
# It does however, make code safer when this cannot be done without involving
# an extra local variable for clarity and safety. Enabling this error, even as just a warning,
# does get in the way a bit if all you want to do is a null to default value release runtime
# safety/fallback assignment. For that use case you have to add a local rule override. With
# null-safety, the need for this kind of null check and re-assignment to default if null,
# pretty much goes away. Considering the comment in:
# https://dart-lang.github.io/linter/lints/parameter_assignments.html:
# "Assigning new values to parameters is generally a bad practice unless an operator
# such as ??= is used. Otherwise, arbitrarily reassigning parameters is usually a mistake."
# One might even think the rule would allow using the ??= operator, but it does not. For now
# I am keeping this lint as warning and overriding locally with
# // ignore: parameter_assignments
# when I need it for the ??= operator, or some copy/paste in of some code that does things
# that needs it too and that I don't want to deal with fixing at the moment.
parameter_assignments: warning
# LINTER Preferences
#
# Disable unwanted or conflicting lint rules.
linter:
rules:
# DO separate the control structure expression from its statement.
#
# https://dart-lang.github.io/linter/lints/always_put_control_body_on_new_line.html
#
# This sometimes makes things more unclear when one line is enough.
# Also single line `if`s are fine as recommended in Effective Dart "DO format your code using dartfmt".
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
always_put_control_body_on_new_line: false
# DO specify @required on named parameter before other named parameters.
#
# https://dart-lang.github.io/linter/lints/always_put_required_named_parameters_first.html
#
# Conflicts with the convention used by flutter, which puts `Key key`
# and `@required Widget child` last.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
always_put_required_named_parameters_first: false
# Do specify type annotations.
#
# https://dart-lang.github.io/linter/lints/always_specify_types.html
#
# Avoid var when specifying that a type is unknown and short-hands that elude type annotations. Use
# dynamic if you are being explicit that the type is unknown. Use Object if you are being explicit
# that you want an object that implements == and hashCode.
# The linter rule link above states this rule is from the Flutter style guide.
#
# I like this lint rule, to me it makes most code intent more explicit, sometimes this helps me reason
# about unfamiliar libs, but it might get tedious when dealing with very familiar ones.
# For people used to more relaxed or no type declaration, it is probably the other way around.
# This rule is of course also in conflict with some other lint rules, most notably it
# violates Effective Dart "AVOID type annotating initialized local variables".
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
# Which I find to be a strange rule, the package lint agrees, with the statement that
# "Types for local variables may improve readability" and keeps that avoid rule disabled.
# Turning always_specify_types lint rule on in a project at later stage is very tedious, fixing
# all the analyzer warnings will take quite some time. Having it on as you write new code
# is not so bad though, the IDE will handle it most of the time.
# Most people probably want this lint rule off, but for now I try to keep it on
# in my projects. I might reconsider this choice later, for example this issue has requested
# a new softer related lint rule that could be used only for declarations:
# https://github.com/dart-lang/linter/issues/1620
# If such a lint rule materializes, I will probably switch to using it instead and turning this one off.
#
# I felt the above long explanation was warranted as a reminder to myself. I am keeping it here and
# the rule setting below to turn it OFF for a day when I might turn it OFF.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
#
# always_specify_types: false
# DO avoid relative imports for files in lib/.
#
# https://dart-lang.github.io/linter/lints/always_use_package_imports.html
#
# This rule conflicts with `prefer_relative_imports` so we turn it OFF.
# I'm still conflicted about which version to use, keeping it this way for now, as support
# for relative imports have improved in both IDE's, but adding imports still often get imported as
# package imports and then you have to edit them manually. Also the relative paths can
# be messy to keep track off, package imports are imo a bit easier from that point of view.
#
# You have to be consistent though, as mixing and matching can cause issues as the same file
# imported with the different options are considered to be different libs/code, this may impact eg
# singletons, service locators and code size too.
#
# When you refactor by changing and moving folders with a lot code in them that other code depends on for imports
# via relative imports, then they get messed up with either main Flutter IDE, VS-Code and AS/IntelliJ.
# Both may fail to do a consistent and and good job.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
always_use_package_imports: false
# AVOID using as.
#
# https://dart-lang.github.io/linter/lints/avoid_as.html
#
# Using `as` is not that bad, especially with the upcoming non-nullable types. Also a bit of a
# legacy left-over from Dart1, should maybe be deprecated.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_as: false
# AVOID annotating with dynamic when not required.
#
# https://dart-lang.github.io/linter/lints/avoid_annotating_with_dynamic.html
#
# Violates Effective Dart "PREFER annotating with dynamic instead of letting inference fail", it
# also conflicts with strong mode disabling `implicit-dynamic`. Turning it OFF as well.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_annotating_with_dynamic: false
# AVOID catches without on clauses.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Using catch clauses without on clauses make your code prone to encountering unexpected errors that
# won't be thrown (and thus will go unnoticed). BUT, there are situations where we voluntarily want to
# catch everything, especially as a library.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_catches_without_on_clauses: false
# AVOID defining a class that contains only static members.
#
# https://dart-lang.github.io/linter/lints/avoid_classes_with_only_static_members.html
#
# Creating classes with the sole purpose of providing utility or otherwise static methods is discouraged
# in effective Dart. Dart allows functions to exist outside of classes for this very reason.
# Effective Dart says avoid classes with only static members:
# https://dart.dev/guides/language/effective-dart/design#avoid-defining-a-class-that-contains-only-static-members
# However, the Flutter style guide says use them when it makes sense:
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#begin-global-constant-names-with-prefix-k
# Colors is an example of such a class, but they still enable this rule in the repo though, go figure.
#
# Like Pedantic, I like util and static classes too, so I will use them going forward.
# Earlier I refactored a project away from this in favor of the Effective Dart style. Converted to a lot
# of kConstants in different const files, but this is more cumbersome to use than static classes. The import
# is simpler with static classes and the code looks cleaner. If you use a lot of constant files, importing them
# is more tedious and you cannot enforce a given 'as' name to have a consistent name space prefix, a static
# class gives you that automatically, thus providing context for the constants.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint enabled : https://pub.dev/packages/lint
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_classes_with_only_static_members: false
# AVOID positional boolean parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_positional_boolean_parameters.html
#
# Positional boolean parameters are considered a bad practice because they are very ambiguous.
# Using named boolean parameters is much more readable because it inherently describes
# what the boolean value represents.
# In principle I agree with the argument against positional booleans. However, positional booleans
# are imo OK when they are the ONLY boolean parameter in a callback and very handy when used in a
# model setter from the callback directly.
#
# Flutter API contain many callbacks with the signature: {void Function(bool) onChanged} often
# for UI toggle switches. To keep things tidy and clean with a model setter for such a callback
# a setter method with a positional boolean is needed, a typical pattern is:
# Switch.adaptive(
# value: model.hideTooltips,
# onChanged: model.setHideTooltips,
# ),
#
# I'm turning OFF this AVOID rule. Willing to reconsider if I get convinced there are better ways and it does
# not get in the way of single none named bool callbacks.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint enabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_positional_boolean_parameters: false
# DO avoid print calls in production code.
#
# https://dart-lang.github.io/linter/lints/avoid_print.html
#
# My default is to have this rule enabled.
#
# Examples may want to print to the console, you might want to do so during development too. I keep the rule here
# to handily disable/enable as and when needed. This lint rule is a good way to find prints statements that you
# may have used during development in code that should not have them in production, so at least before
# committing the code in such projects, make sure to keep this rule enabled by commenting it out here.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint enabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
#
# RELEASE: ENABLE : By commenting it out. (My default).
# DEVELOPMENT: DISABLE : With false value, if the warnings bother you during dev or making a console app.
#
# avoid_print: false
# AVOID annotating types for function expression parameters.
#
# https://dart-lang.github.io/linter/lints/avoid_catches_without_on_clauses.html
#
# Annotating types for function expression parameters is usually unnecessary because the parameter types can
# almost always be inferred from the context, thus making the practice redundant.
# However, since we are using `always_specify_types` we should not have this one ON either as it conflicts with it.
# Also while a bit tedious, it can sometimes improve readability, so let's no force them to not be allowed,
# thus even if you don't use `always_specify_types`, it is possible to sometimes allow specifying
# them on closures when it improves readability.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
avoid_types_on_closure_parameters: false
# DO Use the cascading style when succesively invoking methods on the same reference.
#
# https://dart-lang.github.io/linter/lints/cascade_invocations.html
#
# Disabling this rule, personal preference, using them is fine though, but let's not enforce it.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
cascade_invocations: false
# DO invoke close on instances of dart.core.Sink.
#
# https://dart-lang.github.io/linter/lints/close_sinks.html
#
# Disabling it, may generate false positives. https://github.com/dart-lang/linter/issues/1381.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
close_sinks: false
# DO reference all public properties in debug method implementations.
#
# https://dart-lang.github.io/linter/lints/diagnostic_describe_all_properties.html
#
# Consider using this lint rule if you are making a public Flutter package, for private ones and private apps
# I recommend keeping it off as you probably won't be making diagnostic properties for all your
# classes, unless you are using a data class lib that does it for you via code generation.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
#
# PACKAGE: ENABLE : By commenting it out.
# APPLICATION: DISABLE : With false value. (My default, assume we are making an app most of the time.)
diagnostic_describe_all_properties: false
# DO Use Flutter TO-DO format.
#
# https://dart-lang.github.io/linter/lints/flutter_style_todos.html
#
# Disabled, I do not use Flutter-style todos, but if you are coding for the Flutter repo, then
# by all means do keep it on.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
flutter_style_todos: false
# AVOID lines longer than 80 characters
#
# https://dart-lang.github.io/linter/lints/lines_longer_than_80_chars.html
#
# Using this rule will sometimes force a line of 81 characters to be split in two.
# As long as we try to respect that 80 characters limit, going slightly above is fine.
# For packages keep this rule enabled though, because the pub.dev dart format check will
# penalize packages points if it does not adhere to strict dart format rules, which apparently
# requires max 80 char lines. This rule will then help you find cases where you go over
# and fix them manually when possible. Funny thing is that Flutter repo violates this rule, but
# if you do it in packages for pub.dev you get score deductions, not very consistent imo.
# I may sometimes disable this rule if this is not a package, so I'm keeping it here as handy toggle.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
#
# PACKAGE: ENABLE : By commenting it out. (My default, even if is not a package, I start with this.)
# APPLICATION: DISABLE : With false value. (When/if short lines become problematic. I sometimes like 100 chars.)
#
# lines_longer_than_80_chars: false
# DO define default behavior outside switch statements.
#
# https://dart-lang.github.io/linter/lints/no_default_cases.html
#
# An experimental lint rule maturity wise. Disabled for now until we have NNBD, as it
# otherwise conflicts with `missing_return`.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
no_default_cases: false
# CONSIDER omitting type annotations for local variables.
#
# https://dart-lang.github.io/linter/lints/omit_local_variable_types.html
#
# Conflicts with 'always_specify_types' that is used, so then we can't have this rule either, besides I like
# being verbose and specific.
#
# Other known linters use:
# Pedantic enabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
omit_local_variable_types: false
# PREFER defining constructors instead of static methods to create instances.
#
# https://dart-lang.github.io/linter/lints/prefer_constructors_over_static_methods.html
#
# Dart has named constructors. Static methods in other languages (java) are a workaround which don't have
# named constructors. I don't mind this lin rule, I think it is OK, BUT I noticed that if
# if you want/need to create instances of classes via static helpers in another class, that
# this lint rules complains about it. I'm OK with preferring a named
# constructor over a static method to create an instance from within the same class.
# But this lint rule complained about the above usage too where I think it makes sense to use this.
# This rule currently complains about use cases that imo in some scenarios is impossible to comply with.
# Maybe this is another issue with this lint rule, I should investigate further and report
# it if it is. For now disabling this rule.
# A past now resolved issue with this lint rule was: https://github.com/dart-lang/linter/issues/2149
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint enabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
prefer_constructors_over_static_methods: false
# DO use double quotes where they wouldn't require additional escapes.
#
# https://dart-lang.github.io/linter/lints/prefer_double_quotes.html
#
# This rule is mostly about what style you want to use and enforce, if any. It of course conflicts with rule
# `prefer_single_quotes` "DO use single quotes where they wouldn't require additional escapes."
# https://dart-lang.github.io/linter/lints/prefer_single_quotes.html
# Imo single quotes are easier to type. On my ISO keyboard it is next to Enter and I don't need the Shit key for
# it plus the far to to reach nr 2 key on R1 and also, IMO they don't compromise on readability. Then again
# if you don't care and don't mind mixing and matching, then ALSO turning OFF `prefer_single_quotes` works fine
# too. I thought it was cleaner to stick to one style and this one is easier to type.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint enabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
prefer_double_quotes: false
# CONSIDER using => for short members whose body is a single return statement.
#
# https://dart-lang.github.io/linter/lints/prefer_expression_function_bodies.html
#
# Certainly good idea in many cases, but not always. For example not always suitable for Flutter, which may
# have a `build` method with a single return, but that return is still complex enough that a "body" is worth it,
# and it might not even fit on a single line.
# https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
prefer_expression_function_bodies: false
# DO document all public members.
#
# https://dart-lang.github.io/linter/lints/public_member_api_docs.html
#
# All non-overriding public members should be documented with /// doc-style comments.
# Not necessary for an app or the examples in a pub.dev package. I enabled this for
# public packages, I keep the rule here so I can enable by commenting out this rule here.
#
# NOTE: There is also the lint rule "package_api_docs", that is enabled as well via all being enabled.
# https://dart-lang.github.io/linter/lints/package_api_docs.html
# "DO provide doc comments for all public APIs.", is what it is supposed to do, but only for packages.
# However, if I turn OFF rule "public_member_api_docs", then the "package_api_docs" offers no warnings
# on missing API doc comments alone. So my conclusion for now is that this rule has to be used instead
# to ensure we find all APIs that should have documentation comments in a package as well.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart enabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
#
# PACKAGE: ENABLE : By commenting it out.
# APPLICATION: DISABLE : With false value. (My default, assume we are making an app most of the time.)
public_member_api_docs: false
# DO sort constructor declarations before other members.
#
# I do like this lint rule, but I want to have the default constructor first, followed
# by its properties, after this other named constructors and factories. This rule gets
# in the way of that and forces you to put (often final) constructor properties after all
# the named constructors and factories, making them tedious to find and disconnected from
# where I want to see, read and handily edit them. This is especially the case if there are
# many constructors and factories and they have a lot of parameters. For now, I disable
# this rule and order things as described above, which apart from the default constructor
# properties coming right after the constructor, is the only part where I in practice
# deviate from this rule, so other than that I do put constructors first as well.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Discussion https://github.com/passsy/dart-lint/issues/1
# Flutter repo enabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
sort_constructors_first: false
# DON'T use final for local variables.
#
# https://dart-lang.github.io/linter/lints/unnecessary_final.html
#
# Incompatible with `prefer_final_locals` that I want because having immutable local variables when
# applicable makes larger functions more predictable and easier to reason about, so I
# use `prefer_final_locals` instead.
#
# Other known linters use:
# Pedantic disabled : https://pub.dev/packages/pedantic
# Effective Dart disabled : https://pub.dev/packages/effective_dart
# Lint disabled : https://pub.dev/packages/lint
# Flutter repo disabled : https://github.com/flutter/flutter/blob/master/analysis_options.yaml
unnecessary_final: false
@rydmike

This comment has been minimized.

Copy link
Owner Author

@rydmike rydmike commented Oct 14, 2020

My Dart & Flutter lint rules - A starting point

This is a starting point I often use for my Dart lint rules, with my personal rationale added as comments regarding why I went one way or another.

The starting point is a list of all lint rules that can be found here:
https://dart-lang.github.io/linter/lints/options/options.html

All lint rules are all first included and enabled and then the above setup just disables the conflicting ones or personally not desired ones. For public packages I keep a few more rules enabled as mentioned in the above comments.

I know the 'always_specify_types' rule is controversial and not really needed by Dart, but I like it for the reasons I mention in the comments. I might change my mind about it eventually, but keeping it for now in my own projects.

@MrHallows

This comment has been minimized.

Copy link

@MrHallows MrHallows commented Oct 29, 2020

This is extremely helpful. Thank you for sharing!

Also, I've included the following header comment in the base copy:

# All original source credit and thanks to @rydmike (https://gist.github.com/rydmike)
# for his Gist here:
# https://gist.github.com/rydmike/fdb53ddd933c37d20e6f3188a936cd4c
#
# Include `all_lint_rules.dart` file, which lists all available lint rules as
# enabled.
# Source: https://dart-lang.github.io/linter/lints/options/options.html

Very much appreciated! :)

@rydmike

This comment has been minimized.

Copy link
Owner Author

@rydmike rydmike commented Oct 30, 2020

@MrHallows you are welcome and cool if you found it helpful.
Mostly I had just documented my linting setup and my current personal reasoning behind the choices, so I can recall why I set it up the way I did later and also to have a convenient place to copy paste it from for new projects. A friend also asked what kind of setup I'm using and this was a convenient way to share it.

@MrHallows

This comment has been minimized.

Copy link

@MrHallows MrHallows commented Oct 31, 2020

@rydmike I figured that was the case (posting it here for personal reasons), but since I came across it and found it useful, I thought I'd let you know and say thank you. Mentioning the header wasn't necessary, I know, but as a fellow programmer/developer, I like to give credit to those who deserve it. Plus, if anyone were to ever come across my code and found that file helpful, they could also be directed back to its source. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment