Expose the exhaustive list of hints #622

Activity

1. ndmitchell commented on Apr 16, 2019

   

   ndmitchell

   on Apr 16, 2019

   Owner

   More actions

   See #562 which has a lot of overlap to this. For type, HLint only gives CODE_SMELL, so that's easy enough. For description, would an example be sufficient?
2. sir4ur0n commented on Apr 16, 2019

   

   sir4ur0n

   on Apr 16, 2019

   Author

   More actions

   Thanks for your answers!

   In case it's possible to improve things, an example would be great. Maybe also explain why something is bad (e.g. for performance / readability) but this would be bonus!

   I started toying with hlint test --verbose and removing noise (like file path), some things don't look possible to convert into rules:

   Error: Use bad
   Found:
     readFile
   Perhaps:
     bad
   
   Error: Use bad
   Found:
     Prelude2.readFile
   Perhaps:
     bad
   
   Error: Use Int32
   Found:
     32 :: Int
   Perhaps:
     32 :: Int32
   
   Error: Use after
   Found:
     before 12
   Perhaps:
     after 12
   

   I guess these are test values? I'm not sure anything can be extracted from it.

   Some look good on the description (which is also the technical name hint from Hlint reports, if I'm not mistaken?):

   Warning: Redundant id
   Found:
     id 12
   Perhaps:
     12
   

   The Found/Perhaps part could be interpreted as a counter-example, this would fit for many rules.

   I see the first word is Warning | Error | Suggestion, I guess this would be the severity field of Sonar?

   As for the type, I think for a first version, it's cool to flag all rules as CODE_SMELL.

   I also find duplicates:

   Suggestion: Use forM
   Found:
     flip mapM
   Perhaps:
     Control.Monad.forM
   
   Suggestion: Use forM
   Found:
     flip mapM
   Perhaps:
     Control.Monad.forM
   
   Suggestion: Use forM
   Found:
     flip mapM
   Perhaps:
     CM.forM
   

   I could filter on the technical name (e.g. Use forM) and keep only the first Found/Perhaps example...

   That being said, would you mind explaining why this is hard to build an exhaustive list of Hlint rules? Is there anything a newbie/intermediate in Haskell could do/contribute to improve the situation? (I won't get offended if you reply "Nope, it's too complicated for you", no worries 😄 ).

   Again, thanks for the help!
3. ndmitchell

   added a commit that references this issue on Apr 17, 2019

   #622, skip hints that are fake

   4f2e547
4. ndmitchell commented on Apr 17, 2019

   

   ndmitchell

   on Apr 17, 2019

   Owner

   More actions

   I don't know why things are bad for each hint (I don't record it), but it's pretty much always readability.

   Correct, things like "Use bad" are test values. I've eliminated them - just pushed.

   The found/perhaps is indeed an example of something that triggers.

   Error/Warning/Hint are reasonable for severity.

   There are definitely duplicates, do dedupe them.

   It's hard to build an exhaustive list of hints because they are functions that take expressions and returns hints, so it's not like there is a function for each hint. That said, I suspect that anything that isn't tested is broken, so hopefully we can get close to an exhaustive list with the test approach.
5. ndmitchell

   pinned this issue on Jun 24, 2020