On an IRC channel at one of my workplaces, one of my colleagues pointed to http://wiki.xtronics.com/index.php/IP_Subnet_Masks as a potentially useful resource.
I had a look at it. It would be okay as a first draft, maybe, but it has one substantial problem and one minor problem.
The substantial problem is that it uses "class A", "class B", and "class C" as if they were equivalent to "/8", "/16", and "/24", which is wrong: by definition (eg, RFC 1812 section 22.214.171.124), class A space is 0.0.0.0/1, class B space is 126.96.36.199/2, and class C is 192.0.0.0/3. Even if a piece of class A or B space is assigned or used at /24 granularity, it does not thereby become class C. This usage is common enough that mentioning it would be reasonable, but using it as if it were correct, as this page does, is wrong.
The minor problem is that it doesn't mention noncontiguous subnet masks at all. While they were never used much (I'm the only person I know of who ever used a network set up that way for more than testing) and are used less and less, there are doubtless still a few lurking to surprise people—and a page like this that people come to for help when they see something unexpected is just the kind of place that should at least mention them.
Then, to top it all off, these people who exhibit two symptoms of networking incompetence exhibit a third. I tried to send them a bug report for the above. The page says "If you have some thing to add to this page please send it to the e-mail below"; while it does not have any email address below that, it does have, at the top of the page, a mailto: link with local-part inform@. So, I tried to send mail to that address.
It got stuck in my outgoing queue, saying "451 Could not complete sender verify callout". Not only do they (apparently) think it's a good idea to farm out some of their spam filtering to third parties with no particular reason to do it the way they want, they can't even get it right when they try to do that. I checked my mailer logs and they connected back to me, then dropped the connection 89.978185 seconds into my banner delay, a point at which all the specs agree any client-side timeout should be at least five minutes long.
Well, screw them. Not only are they handing out misinformation and failing to hand out useful information, they're rejecting, for reasons that are their own fault, my attempt to point these problems out to them. I'm not going to put myself any further out to try to help them fix their own error(s).