I only read TFA around the code examples, so please ignore if this point is addressed. The problem I see with this strategy is that it relies on the programmer

I only read TFA around the code examples, so please ignore if this point is addressed. The problem I see with this strategy is that it relies on the programmer or the reviewer paying attention. If I learned something about writing programs in C, assembly or Forth is that is not enough. Code reviews are great but part of a "defense in depth" strategy, meaning that it has a good cost/benefit ratio at the cost of reliability (the ideal solution being formal proofs but not every shop can afford that). Before relying on naming conventions, and when the language won't help you, there's another strategy to be tried: to not let the mistake happen. There's no general solution, though. In this case I would mostly prohibit the use of "dangerous" functions, like this Request(). With C, sometimes teams make it so that dangerous functions such as strcpy will throw an error at compile-time. Same idea; there's most certainly tools for that. Request() would appear in a few places, so that it would trigger the attention of the reviewer. So I would have e.g. a GetField() function that would do Encode(Request(param)) and that would be one of the few functions in the program where Request() is used. Next, there are cases where you need both the "safe" (encoded) and "unsafe" (raw) version of the data. In this case, I would try my best to "jail" the unsafe version in a lexical scope, most certainly a function. This way you don't let the "poison" (the unsafe string) circulate in your system, just like you perform parameter validations at the top of the function, rather that at each use; that would be the equivalent of relying on hungarian notation, in my eyes.