Wrong nameless

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

In my current company, no one mentions the correct naming of variables, this is not serious. We discuss with colleagues the naming styles of tests, whether to use the TestCase attribute in nUnit, arguing about the appropriateness of #region in C #, writing custom analyzers for our projects and drinking smoothies in general we enjoy life in every possible way.

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

foreach (Dot d in dots) { WriteToOutput(dX, dY); } 

Nobody paid much attention to the variable d. Interview, time, nerves, everyone went through it.
')
After a couple of hours I came across the code in the sql script

 select u.* from Users u 

A few minutes later in a nearby script, a piece was found

 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 correct. Indeed, so 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 its bis1, bis2, bis3?

But finished 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 sanity names to selectable fields, but did not name the tables.

Do you know where this habit comes from? From textbooks.

Opening Shieldt:

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

I open msdn :

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

I open Troelsen:

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

Metanit , professorweb - gets 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 "shorty": changes in the code. There was a single-line query with the Products table, the naming is not particularly necessary, left p. Then they added a join on ProductGroups, pg appeared, just to not change the current style. Then a piece of code copied to another request, there is a join on Profiles, as a result, we have p, pg, pr.

Instead of an afterword. In fact, 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 defects lie in the most prominent place?