{"id":398459,"date":"2024-06-29T14:05:20","date_gmt":"2024-06-29T14:05:20","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=398459"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=398459","title":{"rendered":"Guide to naming in code<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

Summary\u00a0<\/h3>\n

We present\u00a0a guide\u00a0to\u00a0name\u00a0entities in code\u00a0based on\u00a0putting naming\u00a0in perspectives of\u00a0semantic\u00a0space, design,\u00a0and\u00a0readability.\u00a0The\u00a0main\u00a0idea is that naming\u00a0should not be considered as\u00a0creation of\u00a0tags, but as\u00a0a fundamental part\u00a0of design\u00a0process, which implies integral and consistent vocabulary to be used. We discuss naming process and naming formalism from these perspectives and we provide guides for practical use. The work is based on 15 years of experience in engineering work, coding and development management in high-tech industries.<\/p>\n

Contents<\/h3>\n

Names in Software Engineering<\/a>
Principles of Name Design<\/a>
Bad Naming<\/a>
Naming Process<\/a>
Fast Method<\/a>
Long Method<\/a>
Formatting<\/a>
Details & Examples<\/a>
Final Remarks<\/a><\/p>\n

<\/a><\/p>\n

Names in Software Engineering<\/h2>\n

Let us consider what a programmer does. He models a situation in life to create a program\u00a0which adds some value to it.<\/p>\n

<\/figcaption><\/figure>\n

While doing this he\u00a0extracts some things from the situation, conceptualizes them, and names\u00a0them. Like a table is a concept of a wooden construction we see, and we name it using a word \u201ctable\u201d.\u00a0Note, all three are different.\u00a0 <\/p>\n

<\/figcaption><\/figure>\n

In all this work\u00a0a programmer\u00a0uses some language to describe the situation with a certain vocabulary.\u00a0This vocabulary defines and reflects meaning we put into our program, so it also defines if the program is modelling the situation well enough to add\u00a0some value to it.\u00a0Vocabulary in turn can be a source for building names of parts of\u00a0a\u00a0program.\u00a0<\/p>\n

We see three\u00a0dimensions meeting\u00a0here: world, thinking, artifact. These dimensions are pair-wise connected.\u00a0\u00a0<\/p>\n

We also see two levels of abstraction meeting\u00a0here: low-level, dealing with a part;\u00a0high-level, dealing with a whole. These are also cross-dependent.\u00a0<\/p>\n

This\u00a0can be visualized in\u00a0a\u00a0triangle model where entities are pair-wise connected.<\/p>\n

<\/figcaption><\/figure>\n

Name is a reflection of meaning and design. When you name properly, you think properly, you design properly, and you use properly. Bad names lead to improper usage, bad design and bugs.\u00a0 <\/p>\n

Programming is also creation of texts.\u00a0Other programmers or the same programmer in future read the text and decode its concepts. Names are essential part of transferring proper meaning, so actions of future maintainers will not harm integrity of the program.\u00a0\u00a0 <\/p>\n

<\/figcaption><\/figure>\n

This shows that naming\u00a0is\u00a0essential part the whole\u00a0process of\u00a0software engineering, so their design impact all the rest in\u00a0it. <\/p>\n

Principles of Name Design<\/h2>\n

<\/a><\/p>\n

Thus, design of names, design of vocabulary and design of a\u00a0model\u00a0should be aligned, so should the principles we use for it.\u00a0<\/p>\n

In\u00a0software engineering, as in any engineering discipline, in most cases\u00a0a model is mechanical,\u00a0i.e.\u00a0<\/p>\n