Wrongly name nonvariables

It all started about 8 years ago. I then wrote one program for mathematical calculations, and my teacher indicated that I incorrectly name variables. He was right: x, xx, xxx are difficult to distinguish in the code. After renaming, they turned into redSegment, greenSegment, blueSegment (in the context of the task, naming was appropriate). Then there were Fowler's Refactoring, McConnell's Perfect Code, Design Patterns of a gang of four ... every day I sank deeper into the abyss.

In my current company, no one mentions the proper naming of variables; this is not serious. We discuss with colleagues the test naming styles, whether it is worth using the TestCase attribute in nUnit, argue about the appropriateness of #region in C #, write custom analyzers for our projects, and drink smoothiesgenerally enjoy life in every way.

Awareness of the problem began with a test assignment of one candidate (all code in the publication changed, NDA).

foreach (Dot d in dots)
{
    WriteToOutput(d.X, d.Y);
}

No one really paid attention to the variable d. The interview, time, nerves, everyone went through it.

After a couple of hours, I came across a code in sql script

select u.* from Users u

A few minutes later, a piece was discovered in the neighboring script

select u.UserName, b.Locked, d.PropertyValueStrings
from Users u
join Bindings b on b.UserId = u.UserId
join Dossiers d on d.UserId = u.UserId
where u.UserName = 'USERNAME'

A dialogue with the author followed:

- Why do you use u, b, d instead of normal names?
- So shorter.

You know, this argument is absolutely true. Indeed, it’s shorter.

and how about

select bi.BusinessIdentifir, bia.SSAFA, IsNull(bia.Bullshit, ‘Bullshit’), bis1.*, bis2.*, bis.*
from businessItems bi 
    inner join businessItemsArtifacts bia on ...
    inner join businessItemsSegment bis1 on ...
    inner join businessItemsSegment bis2 on ...
    inner join businessItemsSegment bis3 on ...
where 
bia.Date = @creationDate
and bi.Staus = ‘RFW’
AND
(
	(bis1.SignIn = ‘Europe’ and ss2.Limit = 42 and bis3.Connection not in (‘Towel’, ‘Galaxy’))
OR
	(bis1.SignIn = ‘USA’ and ss3.Limit = 146 and bis2.Connection not in (‘Trump’, ‘Klinton’))
	OR
(bis1.PNH = ‘SP’ and ss2.Limit = 21 and bis3.Connection not in (‘Stan’, ‘Kyle’, 'Cartman'))	
)

The request is already full of specific constants and filters, is it really necessary to complicate it bis1, bis2, bis3?

But finished off me

SELECT 
     MFID# as MemberId,
     TRIM(ACX) as FirstName,
     TRIM(ABX) as LastName,
     TRIM(FGS) as Suffix,								
     TRIM(c.DSC) as Country,
     TRIM(mm.CCC) as CountryCode,								
FROM {0}.mailfl
    LEFT OUTER JOIN BDSMTAMDRT.MEMFLT mm ON MFID# = mm.MMID#
    LEFT OUTER JOIN BDSMTAMDRT.CTRCOD c ON mm.CCC = c.CCTRY
WHERE mfid# = ?

The author gave sane names to selectable fields, but did not name the tables.

Do you know where this sharperist habit comes from? From the educational literature.

We open Shildt:

var posNums = nums.Where(n => n > 0).Select(r => r);

I open msdn :

IEnumerable squares =
    Enumerable.Range(1, 10).Select(x => x * x);

I open Troelsen:

List evenNumbers = list.FindAll(i => (i % 2) == 0);

Metanit , professorweb - crawls out everywhere

numbers.Select(n => ...), teams.Select(t => ...)

And then artifacts appear in the code, like

team.Select( p => p.Age > 18);

Another reason for the appearance of "shorties": changes in the code. There was a one-line query with the Products table, name naming is not really necessary, p was left. Then we added join to ProductGroups, pg appeared, just so as not to change the current style. Then we copied a piece of code into another request, there join on Profiles, as a result we have p, pg, pr.

Instead of an afterword. Actually the problem is not at all in the "bad" code. The problem is that I have come across such pieces for a year now, and I paid attention to them only now. The question arises: how many more flaws lie in the most prominent place?