Naming Things in Code

27 Nov 202207:24


TLDRThe video script discusses the challenges of naming in computer science, emphasizing the importance of clear and meaningful variable names. It advises against single-letter variables, abbreviations, and including types in variable names, as they can obscure code clarity. Instead, it suggests using descriptive names, units, and avoiding the bundling of functions into generic 'utils' classes. The speaker advocates for a structured approach to naming that enhances code readability and maintainability, ultimately leading to better software design.


  • 🚫 Avoid single-letter variable names as they lack descriptiveness.
  • 📝 Never abbreviate names; they rely on context and can confuse readers.
  • 🖥️ With modern coding environments, the need for abbreviations has diminished.
  • 📊 Don't include types in variable names; let the type system do the work.
  • 🔢 Use units in variable names for clarity, especially in statically typed languages.
  • 🔄 For dynamically typed languages, use descriptive variable names to convey units.
  • 🔧 Interfaces in C# should not be prefixed with 'I' as it doesn't add value to the user.
  • 📚 Avoid using 'Base' or 'Abstract' in class names; they don't convey useful information.
  • 📁 Consider refactoring if struggling to name a class; it may indicate a structural issue.
  • 📂 Grouping functions into a 'utils' class is an anti-pattern; prefer descriptive, modular organization.

Q & A

  • What are the two hard things in computer science mentioned in the transcript?

    -Cache invalidation and naming things.

  • Why should single-letter variable names be avoided?

    -They don't provide any meaningful information about the variable's purpose.

  • What is the argument against using abbreviations in variable names?

    -Abbreviations rely on context that may not be immediately clear, making it harder to understand unfamiliar code.

  • Why is it no longer necessary to include types in variable names?

    -In statically typed languages, the type declaration should clearly indicate the nature of the variable, making additional type information in the name redundant.

  • What is the recommended practice for indicating units in variable names?

    -Including the unit directly in the variable name, such as 'delaySeconds', makes it clear what unit the variable represents.

  • Why is prefixing interfaces with 'I' in C# not recommended?

    -It doesn't provide additional value to the user of the interface, as they are more concerned with what they can call rather than the type of the object.

  • What should you do if you find yourself naming a parent class with 'Base' or 'Abstract'?

    -Consider renaming the child class to a more specific name, as the parent class should represent the general concept, not the base or abstract form.

  • What is the common anti-pattern of bundling functions into a single utils class?

    -It can lead to a lack of clarity and maintainability, as functions should ideally be part of their respective types or organized into classes with descriptive names.

  • How can you improve the readability and maintainability of a codebase with many utility functions?

    -By moving functions to their appropriate classes or creating new classes with descriptive names, and avoiding the creation of a catch-all 'utils' class.

  • What is the importance of following good naming conventions in coding?

    -Good naming conventions make code easier to read, understand, and change, ultimately leading to better maintainability and collaboration.



📝 Good Naming Practices in Programming

This paragraph discusses the importance of proper naming conventions in programming. It starts with the classic quote about the two hard things in computer science and emphasizes the ease of getting naming wrong. The speaker suggests avoiding single-letter variable names and abbreviations, as they lack context and clarity. The paragraph also criticizes the practice of including types in variable names, especially in statically typed languages, and advocates for using units in variable names for clarity. The speaker provides examples and explains how to improve code readability by avoiding anti-patterns such as bundling functions into a 'utils' class.


🚀 Structuring Code for Clarity

The second paragraph focuses on the importance of code structure and how it affects naming. It advises against using overly general names for classes and methods, such as 'utils' or 'helper', and instead encourages breaking down functionalities into more specific, descriptive classes. The speaker provides an example of refactoring a 'utils' class into more focused classes, each with a clear purpose. This approach leads to a more maintainable and understandable codebase, where each class and function has a clear and specific role.



💡cache invalidation

Cache invalidation refers to the process of ensuring that the data stored in a cache is up-to-date and consistent with the original source. In the context of the video, it's one of the two hard things in computer science, highlighting the complexity involved in maintaining data integrity in systems with caching mechanisms.

💡naming things

Naming things in programming refers to the practice of assigning meaningful and descriptive names to variables, functions, and other elements within code. The video emphasizes the importance of proper naming as it aids in code readability and maintainability. Good naming practices are contrasted with bad ones, such as using single-letter variable names or abbreviations.

💡bad naming practices

Bad naming practices are those that lead to confusing, ambiguous, or non-descriptive names for code elements. The video criticizes practices like using single-letter names, abbreviations, and Hungarian notation, which can make code harder to understand and maintain. These practices are contrasted with the recommended approach of using clear, descriptive names.

💡single-letter variable names

Single-letter variable names are discouraged in the video because they provide no context or information about the variable's purpose. This practice is seen as a relic from the days when mathematicians and early programmers valued brevity, but modern programming emphasizes clarity and maintainability over conciseness.


Abbreviations in code are shortened forms of words that can lead to confusion, especially when the context is not immediately clear. The video argues that abbreviations are unnecessary in modern programming due to advancements in technology, such as larger screens and easier typing, and they should be avoided for better code readability.

💡Hungarian notation

Hungarian notation is an old naming convention where the type of a variable is prefixed to its name, such as 'strName' for a string. The video points out that this practice is outdated, especially in statically typed languages where the type system already provides this information, making Hungarian notation redundant and potentially confusing.

💡units in variable names

Including units in variable names is a recommended practice to clarify the context and meaning of the data they hold. For example, 'delaySeconds' clearly indicates that the variable represents a delay in seconds. This practice helps both the author and other developers understand the expected units and usage of the variable, as illustrated in the video.

💡type abstraction

Type abstraction is a concept where the underlying data type is hidden from the user, and they only interact with a higher-level representation. The video mentions types like C#'s TimeSpan or C++'s chrono::duration, which encapsulate the details of time measurement, allowing developers to work with time without worrying about the specific units.


Anti-patterns are common practices or solutions that are generally considered to be ineffective or counterproductive. In the video, the speaker identifies anti-patterns such as bundling functions into a 'utils' class, which can lead to code that is difficult to understand and maintain. The video encourages refactoring these functions into more descriptive and modular classes.

💡code structure

Code structure refers to the organization and layout of code within a program. The video suggests that struggling with naming often indicates issues with the code structure itself. Good code structure should allow for clear, meaningful names without resorting to abbreviations or other anti-patterns.

💡utils class

A utils class is a collection of utility functions that are used throughout a codebase. The video criticizes this approach, arguing that it can lead to a lack of clarity and maintainability. Instead, it suggests breaking down these utilities into more specific, descriptively named classes or modules, which aligns with the practices seen in standard libraries.


Avoiding bad naming practices can lead to better code structure and readability.

Single-letter variable names are not recommended as they lack descriptiveness.

Abbreviations in code should be avoided because they rely on context and can hinder understanding.

The use of abbreviations was once justified by typing efficiency and screen width, but modern development has eliminated these advantages.

Putting types in variable names is unnecessary in statically typed languages where the type system provides clarity.

Units should be included in variable names to clarify the context, especially in dynamically typed languages like Python.

Prefixing interfaces with 'I' in C# is a pattern that may not be necessary, as the consumer is more interested in functionality.

Naming parent classes with 'Base' or 'Abstract' is not helpful; instead, rename the child class for clarity.

Struggling to name something may indicate a problem with the code structure.

Avoid bundling functions into a single 'utils' class; instead, consider integrating them into their relevant classes or creating separate, descriptively named classes.

Standard libraries avoid 'utils' bundles, sorting functions into well-named modules.

Following these naming rules can result in code that is easier to read and modify.

The quote 'There are only two hard things in computer science: cache invalidation and naming things' highlights the difficulty of these tasks.

Avoiding bad patterns can help get 80% of the way to good naming practices.

The evolution of coding practices has made some old habits, like Hungarian notation, obsolete.

Using types to abstract units can improve code clarity, as seen with C#'s TimeSpan or C++'s chrono::duration.

When naming classes, it's important to consider the user's perspective and avoid unnecessary technical details.



The classic quote is “There are only two hard things in computer science:


cache invalidation and naming things”.


I do agree that these are hard to get right, but


they're also easy to get wrong.


And we can get 80% of the way by avoiding


bad patterns.


We're going to talk about


what I consider to be bad naming practices, practices


that if you avoid you’ll force yourself into better naming, the classic


first example you'll see is you shouldn't name variables with a single letter.


I suspect this originally came from when math


and computer science were more or less the same.


Mathematicians pride themselves on being terse.


They like to crystallize down to the smallest, most concise way of expression.


The thing is, you don't need to edit math, but you do need to edit code.


So it's become obvious to programmers that we should avoid using single letter


variable names because they don't tell you anything about the variable.


But I'd argue that you should take this one step further.


You should never abbreviate names, period.


Look at this code.


Can you tell me its purpose?


What about now?


Abbreviations rely on context that you may or may not have.


You spend more time reading code than writing code.


So forcing yourself to understand per system naming patterns


makes it much harder to dig into unfamiliar code.


Abbreviations used to help because of two reasons:


It saved you typing


and screens were 80 characters wide.


But now, when we write code, we get this.


It takes less keyboard strokes than ever to write variable names.


And we have massive 4K screens now.


So there's no real advantage to abbreviation.


Don't put types in your name.


If you've edited older code on Windows,


you'll see something called Hungarian notation.


This is where you'd prefix the type to the variable name.


I think this goes back to before we had good standard types in C,


so everything would basically be int


and the type of the variable wouldn't actually tell you what was inside of it.


But now with statically typed languages,


the type should tell you exactly what you're looking at.


So putting types in your variables is no longer necessary.




it's considered good practice to put units in your variable names.


For example, if you have a function that accepts a delay time.


If this value is in seconds, you should name the variable delaySeconds.


This way it's clear to the user of the function


that they better be putting in seconds.


It's also more clear to someone


editing the class itself what unit they're working with.


But even better than that is to have a type that removes the ambiguity




For example, in C#, the time span


or chrono::duration in C++.


The type abstracts the user from understanding the exact underlying unit.


You need to explicitly ask for a unit back.


Like here, getting seconds back.


For dynamically typed languages like Python,


you sadly can't rely on type declarations to help.


So we'll need a bit of help from the variable name.




people also add types to their types.


In C# there's this pattern of prefixing interfaces with “I”.


This is something I have never understood.


Good code uses interfaces all the time and the consumer doesn't


really care whether it's an interface, class, or abstract class.


They just want to know what they can call.


In this code, we animate an object on the screen.


This is an interface.


If I swap this to an abstract class


or a concrete class, it wouldn't change this code.


Nor would it help the code do anything better.


C# is still following this pattern, even for new .NET library code.


So for your C# code, it might make sense just to follow the pattern.


Since bad style guidelines are better than no style guidelines.


For other languages, I’d definitely avoid.


Another example of typing your types


is if you find yourself naming a class with “Base” or “Abstract”.


This I've never found in a standard library.


If I have a “Truck” class and then realize that


it might make sense to create a parent class instead.


I've seen folks name the new parent class “BaseTruck”.


This isn't a great name because it doesn't help the users of the class.


It still represents a truck.


If you ever find yourself unable to come up with a good name for the parent


class, it probably means that we should actually rename the child class instead.


Instead of “BaseTruck”, let's just name it “Truck”.


And for the child class lets over specify the name.


We'll call it a “TrailerTruck”.


Now, if someone gets a truck, they understand what they're getting.


It's a truck.


And they don't need to know about any of the details of subclasses.


And if they need to know


a specific type of truck, well, then they get the specific name.


Sometimes if you're struggling to name


something, it's actually indicative that the code structure is to blame.


A common anti pattern I see is if there's a collection of functions


used widely in the code base,


but it's all bundled up into a single utils class or module.


If you're thinking of naming code “utils” or “helper”,


you should think if it's really the right spot for it.


Here's some code from a no doubt that processes movies.


There's a bunch of util functions here.


Firstly, we should consider whether some of these methods


actually make sense as a part of their respective types instead.


So this code here, we can actually just move into the movie


class itself.


For some of these, we can instead create a class that represents


a collection of movies and that has the desired methods.


And finally, some of these


can be separated into other classes with descriptive names.


The paging functionality can be moved into its own class,


and we can even make this generic if we want,


so that it can operate on more than just movies.


And the cookie function should really just be in a cookie class.


Now we don't have anything in our utils class, so we can just delete it.


You don't see a bundle of utils in standard libraries


because they can all be sorted into modules that have good names.


So we should do the same in our code.


These few rules will help you write code


that is easier to read and change.


What would you add?

Rate This

5.0 / 5 (0 votes)

Related Tags