I've just spent a load of time on this stuff...
A couple of useful sites:
https://www.lammertbies.nl/comm/info/crc-calculation and
https://reveng.sourceforge.io/crc-catalogue/16.htmI also had some old CRC code, labelled CCITT but actually it turns out to be nothing like the CCITT ones in the above links. And I suspect there is a lot of this around...
I doubt that, for a given CRC
size, different CRCs offer widely differing reliability, especially as most of the time one has little idea of the sort of corruption to be expected. Obviously, there is a chance of a CRC being "right" accidentally, for any random data. In the 1980s, before ethernet became (relatively) cheap to implement, I designed a token ring LAN (for the interconnection of a printer/plotter sharing product called a Multibuffer). This used an 85C30, in SDLC mode, with the SDLC 16-bit CRC (and a Z180 with some dual-port RAM, etc). A totally standalone LAN card, with a nice simple API, much easier to use than an ethernet controller, and a ~2mbps data rate. MIL-STD-1553 physical layer, transformer isolated. To test the reliability I built a pulse generator which would corrupt some portion of a packet. And sure enough, running this over several days, with error counters etc, I was getting close to 1/64k probability of a
good CRC on a
duff packet. This rate could be vastly reduced by simple measures e.g. a checksum would bring it down to 1/(64k*256). And in reality one would also do sanity checks on stuff like addresses...
In any system which uses CRCs, you are likely to need to implement the higher layers. For example a packet not acked
may have been received well; it was just the ack packet which got lost. Lots of permutations of this stuff... To avoid sending the same packet twice in this situation, you have to implement a serial number in the packet. And that serial number has to be "sensible" in relation to ones seen before it, so again you are getting more sanity checks.
Regarding decoding on the fly, in many products where you don't have a lot of power but need to do CPU intensive stuff (e.g. floats, esp. double) it is normal to decode the data speculatively and prepare the response (or whatever action) on the assumption that the CRC will be good.