[{"name":"NoSimpleLetBody","comment":"\n\n@docs rule\n\n","unions":[],"aliases":[],"values":[{"name":"rule","comment":" Reports when a let expression's body is a simple reference to a value declared in the let expression.\n\n🔧 Running with `--fix` will automatically remove most of the reported errors.\n\n    config =\n        [ NoSimpleLetBody.rule\n        ]\n\nThe reasoning is that it is not necessary to assign a name to the result of a let expression,\nsince they are redundant with the value or function containing the expression.\n\nIf it feels necessary to give a name anyway because it helps clarify the context, then it might be a sign that the computation of that value should be extracted to a function.\n\nLet expressions will be reported regardless of whether they're at the root of a function or deeply nested.\n\n\n## Fail\n\n    a =\n        let\n            b =\n                1\n\n            c =\n                b + 1\n        in\n        c\n\n\n## Success\n\nAnything that is not simply a reference to a value declared in the let expression is okay.\n\n    a =\n        let\n            b =\n                1\n        in\n        b + 1\n\nThe rule will not report when the referenced value was destructured in the let expression.\n\n    first tuple =\n        let\n            ( value, _ ) =\n                tuple\n        in\n        value\n\n\n## When (not) to enable this rule\n\nThis rule resolves a minor style issue, and may not be worth enforcing depending on how strongly you feel about this issue.\n\n\n## Try it out\n\nYou can try this rule out by running the following command:\n\n```bash\nelm-review --template jfmengels/elm-review-code-style/example --rules NoSimpleLetBody\n```\n\n","type":"Review.Rule.Rule"}],"binops":[]},{"name":"NoUnnecessaryTrailingUnderscore","comment":"\n\n@docs rule\n\n","unions":[],"aliases":[],"values":[{"name":"rule","comment":" Reports unnecessary or suboptimal trailing underscores in variable names.\n\n🔧 Running with `--fix` will automatically remove most of the reported errors.\n\n    config =\n        [ NoUnnecessaryTrailingUnderscore.rule\n        ]\n\nI don't know how widespread this usage is, but I tend to append variable names with `_` to avoid [shadowing conflicts](https://github.com/elm/compiler/blob/9d97114702bf6846cab622a2203f60c2d4ebedf2/hints/shadowing.md), for instance like this:\n\n    viewName name =\n      case name of\n        Just name_ -> ...\n        Nothing -> ...\n\nObviously when I am able to figure out a better name for one of the two variables, I go for that. In this case, I may rename the argument to `viewName` to `maybeName` for instance.\n\nBut I notice that relatively often, the need for having the trailing underscore disappears, because I changed some code and the variable name that required me to add a trailing underscore has also disappeared. When that happens, the trailing underscore becomes a distraction and I find it nicer to rename the variable to not have that underscore.\n\nThis rule does not propose a fix for the issues (at least for now). I recommend renaming the variables through your IDE, as that will be a simpler and safer process.\nThat said, as we'll see in the following sections and examples, these renames may end up in shadowing issues, so please do these renames with a compiler running next to (or `elm-test --watch` for the changes happening in test files) to notice problems early on.\n\n\n## Fail\n\n\n### 1. Unneeded trailing underscore\n\nWhen a variable has a trailing underscore that could be removed without an issue.\n\n    viewName maybeName =\n        case maybeName of\n            Just name_ ->\n                name_\n\n\n### 2. Top-level declarations containing an underscore\n\nThis rule reports top-level declarations containing an underscore, even when removing the underscore would cause a shadowing conflict.\nThe idea here is that if you have both `viewName` and `viewName_`, someone who looks at the code may have a hard time figuring which function they should use and what the differences are between the two.\n\n    viewName_ name = ...\n\nWhen `viewName_` is only used inside `viewName`, an alternative name that you could go for is appending `Help`, such as `viewNameHelp`, which I've seen regularly often in several packages and codebases.\n\n\n### 3. Let declarations on the same level where one has an underscore and one doesn't\n\n    a =\n        let\n            name =\n                \"Jeroen\"\n\n            name_ =\n                \"Engels\"\n        in\n        name ++ \" \" ++ name_\n\nVery similar to the previous point, we report `name_` because this name is too confusing in the sense that readers won't know which one to use when.\nIn such instances, I believe there are clear benefits from spending a little bit of time figuring out a better name.\n\nHere is another instance where a better name could be given.\n\n    a =\n        let\n            model =\n                { a = 1, b = 2 }\n\n            model_ =\n                { model | b = model.b + 1 }\n        in\n        doSomething model_\n\nIn this example, even simple naming schemes like `initialModel` and `modelWithUpdatedB`, or `modelStep1` and `modelStep2` would be an improvement over a trailing underscore. I'm sure you can find even better names for your specific use-case!\n\n\n### 4. When an underscore is used to avoid a shadowing conflict with a more deeply nested variable\n\n    view model_ =\n        case model_ of\n            Loaded model ->\n                text model.name\n\nIn this case, `model_` has a trailing underscore to avoid a conflict with `model` declared in a deeper scope.\nI tend to find constructs like these to be an indication that either\n\n  - one or both of those variables have a bad name for what they're represent (`model` could be `loadedModel`?)\n  - if they represent the same type, again we have an issue where it's not clear when one should be used over the other\n\n\n## Success\n\nWe don't report errors when there is a reasonable use-case for adding a trailing underscore, or when a variable does not have a trailing underscore.\n\n    viewName name =\n        case name of\n            Just name_ ->\n                name_\n\n\n## When (not) to enable this rule\n\nThis is a pretty personal rule that I'd like to enforce on my own projects.\nI have not yet tested it extensively, but I feel like it could bring some value and bring me some sense of satisfaction when I know that the project adheres to this rule.\n\nI feel comfortable enough with asking people making pull requests to the projects I maintain to make changes in order to follow this rule.\nBut I will probably not enforce this rule in a project where my team is bigger, because this may be too big of a source of frustration for my colleagues, especially if they tend to notice problems in the CI and no way to autofix the issues.\n\nI recommend AGAINST enforcing this rule if you do not agree with the choices I have made, or if you do not have that habit of adding trailing underscores.\nIf you see some value in it, you may still want to use this rule to detect places where naming could be improved and make improvements to these places, but not end up enforcing it.\n\n\n## Try it out\n\nYou can try this rule out by running the following command:\n\n```bash\nelm-review --template jfmengels/elm-review-code-style/example --rules NoUnnecessaryTrailingUnderscore\n```\n\n","type":"Review.Rule.Rule"}],"binops":[]}]