Watch “Felienne Hermans: How patterns in variable names can make code easier to read” on YouTube
Posted by jpluimers on 2024/05/21
A while ago, various sources pointed me to the great video below by [Wayback/Archive] Felienne Hermans: How patterns in variable names can make code easier to read – YouTube.
I responded to the first Tweet with a series of tweets describing my two pet-peeves that I see going wrong when teaching new programmers how to name things (the examples are in Delphi, but I have seen similar shortcuts being taken in C#, VB.NET, and JavaScript being taught in both courses and conference sessions).
The two pet-peeves are:
- avoid abbreviations as those are context sensitive; given software development already mixes technical context (it’s software development!) and domain/semantic context it makes it extra hard to decipher abbreviations
- if you want/need to mix technology and semantics in names (most often you do), start with the most meaningful semantics and end with the least meaningful technology
- if you don’t need technology in your names, at least put the most meaningful semantics and end with the least meaningful technology
Both very well amend what Felienne – a university professor – states in her research backed video:
“Their results show that ‘linguistic code smells’ actually increase cognitive loads,” she said. “Your brain has to work harder to process code that has these type of code smells. So that’s not what we want.”
I saved the [Wayback/Archive] tweets in the [Wayback/Archive] ThreadReader as this text (slightly edited for formatting):
My pet-peeve here is two fold:
if you want/need to mix technology and semantics in names, start with the most meaningful semantics and end with the least meaningful technology
This applies to any development environment, taking Delphi as that’s what I taught most:
In a Delphi GUI application you always have:
- a main form that is a class combined with a variable that both need to go into the same unit file (which in more generic terms is a module) with extensions
.dfmand.pasa main program file with extension
.dprNames then are:
CalculatorProgram.dpr(or justCalculator.dpr)CalculatorMainFormUnit.pasCalculatorMainFormUnit.dfmTCalculatorMainForm(the Delphi class for the main form)CalculatorMainForm(the Delphi variable for the main form)The last two are both in the
.dfmand.pasfile- Avoid abbreviations whenever possible as abbreviations are always context sensitive. Since in an application you can have both technical context and semantic context it is easily to confuse both.
This goes against how most Delphi programmers are being taught with names like these:
Calc.dpruFrmMain.pasuFrmMain.dfmTMainFrmMainFrmor if you are even less lucky saving with IDE auto-numbering:
Calc.dprUnit1729.pasUnit1729.dfmTForm1729Form1729The 1729 is a tribute to [Wayback/Archive] Ionica chose a number (and we made it difficult) – news – Maastricht University
Welcome back from the long Heidelberg-Leiden train trip Ionica!
Via at least these:
- [Wayback/Archive] /Fay-lee-nuh/ on Twitter: “Cool to see the @neverworktheory videos taking off!”
- [Wayback/Archive] The New Stack on Twitter: “Best Practices for Naming Variables: What the Research Shows …@DavidCasselTNS @Felienne #NamingVariables”
- [Wayback/Archive] Best Practices for Naming Variables: What the Research Shows – The New Stack (a full article about the video, so if you prefer reading over watching: definitely recommended reading)
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment