This was meant as a comment to @zwol post, but became too long for one...
You seem to be missing the point of code-prettify (similarly for prism.js for that matters). It is a regex-based syntax highlighter, it does not implement a full parser for each language it supports. This is what makes it lightweight and fast, and by default works passably for a range of languages even ones not explicitly defined in the library (should work in a best-effort way for most C-like or HTML-like languages). But it also means it can fail in certain cases that only a proper parser could handle (think contextual keywords, or constructs like string interpolation difficult to do right with regexps alone). Not to mention languages notoriously difficult to parse (say Perl).
Keep in mind that in code-prettify there's a "default" handler (selected when you don't specify a language, or a set a non-existing one), plus variations in the core lib for languages like "lang-cpp", "lang-java", "lang-py", etc. They are similar but not the same.
In fact if you look at the implementation, C/C#/Java/Python/JS/etc. are all handled by the same function sourceDecorator which accepts options to customize things like:
- list of keywords
- type of comments (hash or c-style)
- type of strings (single/multi-line, verbatim, tripled-quoted, etc.) and such.
Even then the list of keywords is cleverly built by starting with common ones, and adding each time language-specific ones on top, in order to keeps the library size to a minimum. As a result, some keywords would be missed or falsely highlighted.
You'll also find a rule in the common highlighter where it considers identifiers that start with a capital letter as a type (PR_TYPE styled differently). Again this was an ad-hoc rule following the CamelCase naming convention. Short of actually parsing the code to properly detect class/type names, this is a cheap alternative.
While you can start adding code to handle special cases fixing specific languages, it will certainly start to increase the code size. You might say let's just do this for C# or insert-you-favorite-language, but then where do you draw the line?
The same idea applies to the whole library. It was designed with the goal that it should work decently for most languages using just the base lib prettify.js. And yet it allows you to extend it by registering extra handlers lang-xxx.js for languages where you want more control at the expense of bigger size (more JS to download).
If you look in the directory of contributed modules, you'll find handlers for languages which the base lib mostly fail on (say lisp-like langs). But you'll also find somewhat redundant handlers for languages that the base lib can actually deal with by default (to a degree), but their authors felt they wanted a more specific/correct handling of said language syntax. The biggest offender here is the list of keywords.
For a site like Stack Overflow where you don't want a bloat of JS files, it's up to SO to pick and choose what extra language handlers to include...
