Rethinking errors, warnings and links

I founds this great article that talks about how errors in code ought to treated by a compiler and other tools.

http://neugierig.org/software/blog/2022/01/rethinking-errors.html

Some of the key takeaways:

  • The severity of a problem can be different at different levels of the code workflow: Local dev builds can be more forgiving than checks prior to commiting a change.
    • Problems that the compiler identifies as making the code not work, must not necessarily block compilation. Type errors for example could just be implicitly converted to runtime errors. That can be useful for dev builds when you don’t care about the error that gets introduced and can fix that later.
    • For this it’s necessary to signal at what stage a check runs and which severity rules apply there.
    • Getting feedback earily is useful, but you should avoid warning overload.
  • When a tool (compiler, linter, etc.) identifies a problem, it can often also suggest or even automatically apply a fix for it. There may be multiple fixes to choose from.
  • Some problems have a low confidence and might identify false postibes. Such should be marked in code to surpress recognition. This can be a valid fix.

I think these considerations can be useful for enhancing the Crystal toolchain.

3 Likes

Would be interesting to have a compiler that feeds its error and warning logs to a central repository so that it can be analyzed to identify which are the most common errors or hiccups programmers run into. This data could be used by the compiler developers to derive insights and perhaps tweak the language. Or perhaps as input to see where programmers get hung up and where additional documentation is needed.

2 Likes