Nomenclature for radio, checkbox, select, inputs, etc.

The current trend is not to use such prefixes. The reasons are several

• Using prefixes in field names, variables, and objects usually comes from an outdated technique to make it easier to understand the code, when it was difficult to trace where those values came from.
• Prefixes and suffixes of this type do not add anything useful to names, on the contrary, they pollute the code. In addition to being one more standard for you to decorate, they make you type and read those characters more often.
• The current trend is to make the front end independent of the back end . If you bind the field names to the type of the element in a <form> , this means that a change to the screen will force a change in the service.
• Even on the front end, the trend is to separate the business and control rules of the HTML page itself. Libraries like Angular, React, and many others provide mechanisms for working with fields independently. Even with jQuery you can usually work with forms without having to% s of% s to check the type of each field.

With all this, I do not want to say that you should never adopt some kind of pattern with suffix and prefix, but you should consider the impact of it.

Perhaps in your particular project, given the set of tools and stack of technologies you use, this makes sense. Overall, within the context of the technologies I have knowledge of and the tools I use, I do not think it does.

I usually use the first three characters to set the field type and then the rest to the field itself, for example: sel_uf, chk_active, edt_name, edt_endereco ... and so on.

Legal your interest in following standards. This is very good for easier code maintenance.