> The problem with including the name of a pattern in the name of a class is that this permits you the feeling of having created a useful name without actually having done so. Pattern names don't generally reflect concepts in your application

I thoroughly disagree. In my experience, the domain of the app doesn't really matter when you're trying to make sense of the architecture of a software to fix that bug you were commissioned for, especially when you had never heard of that software two days ago and you'll never hear of it again in two days.

On the other hand, having a way to very quickly know which class does what in a software sense (through the patterns in the name) allows to make a rough diagram of the software in 5/10 minutes just by looking at the class list which is to me crucial to get an understanding of whatever mess is happening in there

> I mean, if I see a class named ReportVisitor, I immediately know what the author’s intent was, and what the structure of the code is.

https://blog.cleancoder.com/uncle-bob/2015/07/05/PatternPush...

I generally agree with the rule and the reasoning given for it. But I think the worry about the "Fake" suffix here is missing a crucial point.

This is test code. In test code, the "business" at hand is exercising the production code. To put it another way, test code doesn't have the same business domain as the application code.

Therefore, in test code "Fake" is a domain-specific term, and it is perfectly appropriate as part of a class name.

This classic rant by Steve Yegge gets shared almost every time object oriented design pattern debates come up on HN, but I'll share it again since new members join regularly: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

You may or may not agree with it, but it does frame the debate in an interesting way.

I think naming should reflect whether a class encodes business logic or is ‘glue’ to make that work.

Nowadays, many people use languages with huge libraries. Consequently, most logic is business logic. There, name classes (and functions, and argument names) after their business use, not after their implementation.

However, parts that aren’t business logic such as wrappers of external libraries or generic containers you have to implement because they aren’t available in the language’s ecosystem should use generic names, and can use pattern names, because those tell callers what they do.

As a made up (and not that good) example, one would have

   def pow(a,b)

but

   def valueAfterNYears(initialValue, interestPerYear)

(Yes, these aren’t functionally equal. That’s part of why I said it wasn’t that good of an example)

This blog reminds me of one of the most frustrating naming patterns I see among coworkers, former students I TA'd, and open-source code: reversing the adjective or adverb with the noun. I attribute it to language barriers but seeing, in this blog, "VerseFake" instead of "FakeVerse" peeves me.

Its a VERSE class, not a FAKE class. It just so happens the class is described as a "fake" so...FakeVerse. Its like saying "Hey look a person tall!". While it sounds silly in english its incredibly pervasive in programming.

Another common pattern that drives me nuts is when people prefer nouns over strong verbs in functions. doDatabaseRestore instead of restoreDatabase.

It just makes sense, because you have the "parent class" in front and can order classes in docs etc. "AnimalLand", "AnimalWater", "AnimalAir" instead of "LandAnimal", "WaterAnimal" and "AirAnimal".

In fact I would probably prefer databaseRestore to restoreDatabase for the same reason because it would allow to cognitively group database methods in your flat namespace instead of grouping restore methods.

> In fact I would probably prefer databaseRestore to restoreDatabase for the same reason because it would allow to cognitively group database methods in your flat namespace instead of grouping restore methods.

This is especially important in pure C. If OOP-style programming is adopted, databaseRestore() can be strictly interpreted as a method of the Database class without ambiguity, and its first parameter is the object the operation is applied onto. In a sense, even old C & POSIX functions such as fopen(), fclose(), fseek() can be seen as a rudimentary form of OOP. On the other hand, restoreDatabase() may perform other operations that change the state outside of the database object.

> restoreDatabase

It may do anything because it was probably written by an intern

That also reflects on the ordering of files for navigation. I'd rather see files `VerseFake.source`, `VerseReal.source`, `VerseOther.source` next to each other. (Unless there's a way to extend the namespace and just have `Verse/Fake.source`, ...)

Completely agree. The same thing pops up with filenames, as well as many automation tools where functions end up being commands. Python's fabric for example has a help function that dumps out possible commands in alphabetical order... the "restore_database" convention ends up being painful to sort out visually.

I think it depends upon your project. E.g. how far do you plan to take this - would you call it an AnimalCheetah or a Cheetah? If the latter, I would err on the side of "LandAnimal". Also, if your project is 100% about animals I would probably prefer "LandAnimal" too - otherwise you're likely to end up with a bunch of classes starting with AnimalXYZ and all you're doing is adding noise to your project when everything in it starts with Animal.

> would you call it an AnimalCheetah or a Cheetah?

Depends on whether you're Hungarian :P

In all seriousness, I'd go with the prefix if these are part of a large flat namespace, but if there were a lot, then they should move to their own package and become `animal.Cheetah`.

+1. It took a while for me to get on board with this at my company but I'm now a huge fan. We name our APIs "FooCreate", "FooUpdate", "FooDelete", "BarCreate", ... for nicer sorting and grouping, even though it's the opposite of how you'd say it in common English.

If you are choosing a less understandable name just so your docs are sorted we have bigger problems :). It’s a strictly worse name - one tells you what happens when you call it while the other sounds like a variable name and it isn’t clear it does something

Putting the common word first also helps IDEs with search and tab-completion. Type "Animal" and you get a list of Animal-things (classes, functions, variables, or whatever) that apply to the context you're in. (Edited for clarification)

Is this is just a more mathematical convention?

You write a_b where in english you'd say "b a". eg. Graph_users -- the user graph.

In mathematics the data element (noun) comes first and is differentiated by some property (graph_user, graph_product, etc.). For the sake of easily tracking what's going on.

So it makes complete sense to have VerseFake, VerseReal, etc.

Idk what you mean by mathematics since mathematics rarely deals with elements from different levels in a hierarchy without renaming.

Important influences probably include

- Lexicographic ordering, (programming) method access, directory path (which influences package namespaces)

- Romance languages put qualifiers after the bare noun by default. You have vestiges in English in titles like Secretary-General, via Norman.

Eg., in english, "consider two kinds of graph: unweighted and weighted. Call them G_u and G_w..."

In mathematics your notation corresponds to Noun_adjective, pretty universally. I have never seen the converse.

"Consider a statistical model trained on UK data and a comparable one trained on US. Call them f_UK(x) and f_US(x)..."

"Compare a voltage applied across a resister, V_r with a voltage across a diode, V_d..."

"Consider the population growth of rabits (dP_r/dt) vs the population growth of foxes (dP_f/dt)..."

A notational description of a problem, using mathematics, always leads with the noun.

I have always considered the same phrasing in programming to just be this same mathematical convention.

"FalseVerse, RealVerse, ComplexVerse" reads weirdly to me. My strong preferece, as a physics grad cum data scientist, is VerseFalse, VerseReal, VerseComplex...

V_f, V_r, V_c

The particular variation follows the general structure, in notation.

You're tunneling in on subscript notation. Consider also max f, diam C, edge(G).

In programming you also have contrary examples, e.g. FooObserver vs. BarObserver, especially when FooObserver's implementation and BarObserver's implementation are little alike they have very different roles in the application.

a_b in maths is pronounced "a of b" in English, and is often intended to be equivalent to a(b).

Superscripts in maths is closer to concatenated class names, as it separates it from being a function of something.

Subscript to "of" doesn't always work.

A model trained on UK data is f_uk. It isnt "model of UK"... its a model of, eg., prices for goods.

f_UK is more like "the UK's model (of prices)"

I think the better way to interpret the mathematical convention is ObjectOfStudy_variation

...which is the convention being used in programming.

Kind of. Pronouncing a_b as "a wrt b" should work though.

With f_uk, it could mean a model with parameters trained for UK - "theta uk".

In my view, it's nice to have subscript-like things in the constructors. Ex:

uk_price_model = PriceModel(uk_model_parameters)

f = goods price model

uk = United Kingdom

f_uk = goods price model of the United Kingdom

Seems to work. Did I misunderstand?

Has nothing to do with language barriers. And more to do with style. I woukd say the VerseFake is how most people would name it.

Many languages (other than English) are happy having adjectives behind.

As other commenters have observed, plenty of great reasons for doing so.

You’re not programming in natural language and you’re trying to bring some natural language semantics into programming.

Please don’t. VerseFake is because the natural sorting will sort VerseFake together with Verse.

You, on the other hand - seem to have never worked with codebases that are large enough to find anything in them.

Good luck finding the right function when you call everything starting with a verb.

In programming you start with an Entity and are given a set of Verbs that are applicable to that entity, not vice versa.

You obviously studied philosophy and not engineering if you are asking questions like that.

Pretty silly reply. No need to attack. I’m fairly certain code bases can’t get much bigger than the ones I’m working on. If you abandon the idea that names should be read in a natural manner why use words at all? What a silly notion.

Many different languages style guides actually prefer verbs for functions as it makes it clearer an action is taken.

Finding function names is very easy with either approach. You have bigger problems and don’t know what you are looking for if you can’t find FakeVerse instead of VerseFake. Why is LandAnimal acceptable over AnimalLand? Why choose AnimalFast over FastAnimal? There is no reason those should be chosen: sorting is a poor argument as the loss in clarity is too great.

Because all namespaces in all routinely used languages are com.land.animal and not animal.land.com

So there’s no reason in naming functions any differently when Entity within the name is just another namespace.

Also I don’t really understand why have the function name “restoreDatabase” when you could just put that function as “restore” within a module called “database”.

So you’re kind of missing the whole point of where the prefixes rather than suffixes come from.

> Good Morning/Afternoon/Evening as the case may be.

This is very inefficient. Try this instead:

> Good day.

Although once you do that, you start to recognize that the entire construction might be unnecessary in this context.

First three lines of the article were so unnecessarily wordy.

For an article that is supposed to be about effective communication.