So let's take his example and reverse it. At first glance, what does this code do? fetcher = repolib.IndexFetcher(args.arch) counts = collections.Counter()

So let's take his example and reverse it. At first glance, what does this code do? fetcher = repolib.IndexFetcher(args.arch) counts = collections.Counter() for repo in fetcher.get_repos(): for file in repo.files: counts[file.name] += 1 for repo, count in counts.most_common(10): print(repo, count) Can't really tell, the names are too short. It's clear to him right now because he's intimate with the code. I'll bet it won't be clear to him in 6 months after he's crammed 100,000 lines of unrelated code into his brain. It certainly won't be clear to some poor sod with zero familiarity who has to come in behind him and maintain it. His basic premise is correct: Names should be as short as possible while still being clear. Unfortunately he didn't follow his own premise. Err on the side of too long but clear, because maintenance is 90-99% of the project's life cycle and reading code is at least 5x harder than writing it. You should name variables/methods as if you won't be touching it for 6 months and you want to be able to have a decent understanding of what it does within 5-10 seconds of reading it.