<opinion>
Explicit enumeration makes sense in legal documents, but CoCs are
more aspirational so I don't think it makes sense in this context.
You will end up either having to constantly add new things to the
list, or declare that the list is non-exhaustive (in which there's
not much point in enumerating in the first place).
This is doubly true given the inherently woolly realm of appropriate
interpersonal interactions that a CoC is implemented to moderate.
Also, remember the KISS principle. Personally, I think this is the
pinnacle of CoC design: https://github.com/karlgroves/dontbeadick
However, I'm sure there is a slightly-more-professional middle
ground ;)
</opinion>
I had to use some RegEx-fu for this. Specifically:
```bash
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/\(p\|l\|a\)_\(str\|bool\|int\|obj\|flo\|arr\)_//g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/MCI_Footnotes/Footnotes/g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/C_\(INT\|STR\|FLO\)_//g' {} \;
```
This should have covered all the bases.
In my testing I encountered one error caused by these changes.
In the `add_select_box` function in `/class/dashboard/layout.php`,
there was a function parameter called `$p_arr_options` and a variable
called `$l_str_options`. Removing the Hungarian notation caused an
error as these two variables were both now called `$options`.
This has been fixed, and I like to think that that will have been
the only naming conflict, but I think it is more likely that there
maybe others. Further testing is required before I am happy calling
this release-ready.
Close#34, progress #36
This dir has been kicking around for a while as a holdover
from the big codebase standardisation. There's no point
keeping the dupe files for now, but I'll come back to this
again later.
