Nomenclature for radio, checkbox, select, inputs, etc

Asked

Viewed 455 times

3

Which is a good name to define these types of inputs?

  • chk_questao1
  • rdo_questao2
  • txt_questao5
  • slc_questao3

Which nomenclature standard is best? Is there any such thing as good practice?

  • 2

    On the server, do you need to know the type of element? In my opinion these "chk" only get in the way, you will have to write line by line instead of having a loop that goes from 1 to n, concatenating "questao+n". I use only the name of the same parameter, questao is fine. If it’s an array, just use questoes[]. Anyway, there’s no right answer, anything you read here will be based on opinions.

  • If, for example, in your database, the column is str_questao_1, in your html the field is slc_questao_1, in his controller the variable is pst_slc_questao_1, does not become a mess ? Leaves everything a name only, let the field name (select, textarea, input) follow the same column name in the database. The comrade’s answer above is good, for a collection, use array, but do not get prefixed.

2 answers

3

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

  • Using prefixes in field, variable and object names in general comes from an outdated technique to facilitate understanding of code, when it was difficult to track where these 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 another pattern for you to decorate, they make you type and read these characters the most every time.
  • The current trend is to do the front end independent of back end. If you link the field names to the type of the element in a <form>, this means that a change in the screen will require a change in service.
  • Even at the front end, the tendency is to separate the business and control rules from the HTML code page itself. Libraries like Angular, React and many others provide mechanisms to work with fields independently. Even with jQuery you can, in general, work with forms without having to do ifs to check the type of each field.

With all this, I don’t want to say that you should never adopt some sort of standard with suffix and prefix, but that you should consider the impact of this.

Perhaps in your specific project, given the toolkit and the stack of the technologies you use, that makes sense. Overall, within the context of the technologies I know and the tools I use, I don’t think it does.

0

I usually use the first three characters to define the field type and then the rest for the field itself, for example: sel_uf, active chk_name, edt_name, edt_address... and so on.

Cool your interest in following patterns. This is very good to facilitate code maintenance.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.