More checks

[Mats Stijlaart]

• Exceeded line length
• Unnecessary List.concat when concatenating only fixed size lists.
• Record type aliases should be formatted multiline when exceeding N fields. (#24)
• Functions where 'too much' happens.
• Function should be moved to another module for better encapsulation.
• Undocumented function that is exposed by module.
• Use alias for complex 'thing'. This can be done by inspecting signatures.
• Use point free notation where possible (\_ -> b to always b and \x -> List.map f x to List.map f)
• Determine untested code.
• Use multiline string instead of concatenated single line string.
• Use list concatenation instead of multiple ++.
• Replace function with a function provided by elm-lang/* or elm-community/*.
• Magic numbers.
• Check for unnecessary port modules (#45)

[Noah]

• Use of Regex.regex as a non static function (runtime error abound) (#46)
• Use of Core's Array package (#51)
• Functions defined in let bindings (#61)

[Ilias Van Peer]

• use of Random iso Random.Pcg
• using current time as a random seed rather than a port

[Felix Lamouroux]

• For functions that have a record as an argument: check if only few (e.g. up to 3/configurable) fields are used and suggest to convert to individual parameters.

One of the "big code-smells" to me are view function that take in the whole model to print e.g. one field. This makes the view function very "potent".

[Ilias Van Peer]

Use point free notation where possible (\_ -> b) to always b and \x -> List.map f x to List.map f)

While I definitely agree with the second point, I do want to note that the first one seems in direct conflict with the noRedInk elm-style-guide which makes a decent case for \_ -> over always.

There's also the case to be made for eschewing overly point free code in performance critical code (say the inner loops of datastructure manipulation), though that's more relevant for library code as opposed to application code.

Sort of going on a tangent here, but I just realized that you'll be able to differentiate between application bundles and library code in 0.19. Might want to create slightly different presets for those..

[Mats Stijlaart]

@zwilias Thanks for pointing that out. This kind of information is valuable :).

[Ollie Charles]

#89 requests a warning on excessively indented code.

[Gabriel]

Another simple metric to check is to count the number of lines in modules and functions. More than once I have found myself trying to understand code from others with files with thousands of lines and functions with hundreds of lines. I like the way how plato shows that info and the complexity of the code.

[Anthony Deschamps]

Matthew Buscemi just published an Atom plugin, elm-lens, which (among other things) warns about items that are exposed but not externally referenced.

• Exposed item with no external references

This might be a case where applications and libraries should be treated differently.

[Andrey Koppel]

• Internal module used outside of it's related module.

E.g.

I have ModuleName and ModuleName.Internal. I want to be sure that ModuleName.Internal could be imported only by ModuleName. And not by some other modules.

Good

module ModuleName exposing (something)

import ModuleName.Internal

Bad

module OtherModuleName exposing (something)

import ModuleName.Internal