4 ms·
It just makes sense, because you have the "parent class" in front and can order classes in docs etc. "AnimalLand", "AnimalWater", "AnimalAir" instead of "LandAn
by ofrzeta 6y ago
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.
- acidbaseextract 6y agoCompletely 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.
- segfaultbuserr 6y ago> 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.
- heavenlyblue 6y ago> restoreDatabase It may do anything because it was probably written by an intern
- viraptor 6y agoThat 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`, ...)
- bcrosby95 6y agoI 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.
- caylus 6y ago> 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`.
- caylus 6y ago+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.
- dcuthbertson 6y agoPutting 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)
- jzoch 6y agoIf 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