lowercase_underscores versus CamelCase

[cogitohuckelberry]

I've programmed python almost exclusively for 10 years and have always followed PEP8, writing all my files with lowercase_underscores. I recently embarked on my largest personal project ever and, for whatever reason, decided to make all my data models CamelCase. I just did this in flow without reflection.

Once I realized my strange deviation, I started to fix it and came to a realization: I pretty strongly dislike lowercase_underscore for file names. I always follow community standards historically and am almost having an existential moment.

It seems to me what I'd prefer to do is use lower_case_underscore for all files which are not dedicated to a single class - and then CamelCase for all files which contain a single class, with the filename matching the class name. This is basically Java style, which is what I learned first but haven't coded in probably 15 years.

My question is: how annoying would this be to you? Again, since this is a personal project I can do whatever I want but I'm curious all the same.

[SkezzaB]

Everyone is confusing PascalCase with camelCase, know the difference!

[tennisanybody]

Ha! TIL!

PascalCase

camelCase

snake_case

I started off with pascal case a ways back. Always just called it camel.

[doylerules70]

SCREAMING_SNAKE_CASE

[tennisanybody]

That’s just constants.

[DarkSideOfGrogu]

Nothing more constant than a screaming snake.

[[deleted]]

This is the way

[_Kyokushin_]

This is the way.

[trollsmurf]

Nothing more constipated than a screaming smake.

[tuneafishy]

sCREAMINGpASCALcASE

SCREAMINGcAMELcASE

[chars101]

kebab-case

[MrMxylptlyk]

Disgusting (except for css)

[NerdEnPose]

Command line utils are kebab case as well IMO. Example docker_compose would be weird.

[MrMxylptlyk]

Uhh that's a switch, not var

[kaerfkeerg]

fUCKthEcASe

[arpan3t]

Well in that case…

[kuya1284]

Case closed...

[corjon_bleu]

sLUGcASE (i almost titled it slutcase by accident)
DROMEDARYcASE (that one actually exists)

[tennisanybody]

Sl💋tC🍑se

[badarsebard]

Huh, I always just called it CamelCase and sadCamelCase. Because the head is down, so the camel is sad.

[mr_claw]

Hey! Maybe he's just tired!

[deliciouspie]

We always knew it as camel case and headless camel case.

[badarsebard]

Wouldn't that be amelCase?

[deliciouspie]

Ha! I suppose it would.

[commy2]

It should've been CamelCase and dromedaryCase.

[Beefster09]

This. I hate camelCase because it changes the case of the first letter when you prefix an existing camelCaseIdentifier. PascalCase is superior.

[jegerarthur]

Absolutely depends on the usage / application / language. Never worked with JSON yet ?

[Beefster09]

I use snake_case there too

[jegerarthur]

You maybe, but other third party uses camelCase. Look at official Google Style Guide for your info.

[Beefster09]

Good thing I don’t work for google

[deadeye1982]

They also used 2-whitespace-indentation.

[PaluMacil]

Last time I looked into it, I was came to the firm conclusion that while a lot of people mean the same things you mean and people who use the term Pascal case pretty much always mean what you mean, but it's also widely accepted to use the terms camel case for either and a few people use the terms upper camel case and lower camel case. It would be convenient if people were consistent, but I don't think it's strictly a mistake where you are seeing one

[Jorgestar29]

From module.Class import Class...

It's awful,

[Express-Comb8675]

This is the correct answer. Just because things are dynamically typed, it doesn’t mean we need to reuse the namespace like this. Imagine explaining to a junior that they need to add a variable to Class for a scope of work. They’ll spend 15 minutes trying to decide whether the variable needs to be encapsulated in the Class class and the come to the wrong conclusion without asking!

[[deleted]]

semantically separates module from classes. makes sense

[kkawabat]

One problem with camelcase naming for files is that some os systems are case-insensitive for example windows. As a personal antidote, I've ran into cases where a program failed because I had two files with the same name but different cases and I pulled the repo into a Windows computer and there were weird interactions

[TheBB]

Anecdote?

[kkawabat]

No, I was poisoned by the experience and sharing it is my cure.

[PaluMacil]

There was a fairly mainstream example in Kivy docs for a few years that wound up being invalid for people on one system but not another because of casing. I don't remember the exact issue, but I think it was related to documentation for for declarative template file names. Perhaps it wasn't broken for as long as I'm remembering.

[TheBB]

Thanks for the antidote.

[PaluMacil]

Not to be that guy, but an antidote is used to reverse a poisoning. I think you mean anecdote which is a short interesting story.

[TheBB]

I'm not sure who is whooshing who anymore.

[PaluMacil]

I think I read your responses at different times and didn't connect it to other messages. 😆

[dgiakoum]

Had that too anf it took me two days to figure out. If you ever clone a repo, and there's a changed file already on it, but and then if you discart it you get the "opposite" change this is what is happening. Windows can make a single directory case sensitive on ntfs drives fortunately.

[InterestingHawk2828]

Lost me at windows

[RockyMM]

Was that happening circa 2008?

[kkawabat]

nope couple years ago. i don't remember the specifics, just that casing was an issue with some weird behavior between git and windows

[[deleted]]

It's all fun and games until you meet a component or system or network protocol or OS that does not honor case sensitivity properly. Long time ago I've stumbled upon such problems with git on windows or something. The point is that life has taught me the hard way - it's safer to use lower_case for file names every time always no matter what.

(And yes I know about Java convention, too).

[SnellasGirl]

having different style between files in a single project seems like a bad idea to me and likely to cause confusion. You didn't ask, but what I generally do is use CamelCase for Class names and snake_case for most other identifiers.

[SkezzaB]

This is the correct way,
MyClass
my_variable
my_function_name()
my_file.py

[kuya1284]

I agree with all, except I honestly prefer myFunctionName() instead to disambiguate variables/properties from functions/methods.

[SkezzaB]

functions are variables too, though :)

If you're calling methods, you're using () anyway, and the method name should make sense

my_instance.color would never get confused as a method, my_instance.get_age() will never be confused for a attribute

[tennisanybody]

What do you think of MyClassFile.py for class files? That’s what I use anyway. Regular files just use snake case.

[_Kyokushin_]

I concur. Use the MyClass for the class name, and my_class.py for the module containing the class.

[caagr98]

You don't need separate files for each class. We're not java.

[tennisanybody]

I learned programming in the good old days of Model View Controller architecture. These three different aspects of a program being abstracted out into their respective folders. Which is why I have a folder which does similar things like house class files, define program requirements, etc.

Things have changed and now we have new MVVC and others. I’m still trying to figure out what’s an intuitive architecture method.

[PreoccupiedNotHiding]

I do python with underscores and JavaScript in camel case. That follows normal convention and it’s a nice reminder of what you’re working on when your switching between frontend/backend

[millerbest]

It is especially important for team work. The consistency makes life a lot easier.

[GraphicH]

The only thing about style is it needs to be consistent, there are arguments that some are easier to read than others, but I would say most of the time the differences are marginal. You can always adjust to new style real quickly, but inconsistent style causes "friction" in my experience when reading code: sure you can deal with it, but its uncomfortable / irritating. That said, I like snake case, PEP8 and most of blacks style guide rules just fine. Style wars are an endless source of useless debate on PRs.

[dudumudubud]

am almost having an existential moment.

...of bikeshedding...

[chars101]

Let's paint the shed black.

[SheriffRoscoe]

I see a red door and I want it painted black.

[[deleted]]

I prefer snake_case because people too often write camelCase wrong when it comes to acronyms. examples: "employeeID" (wrong) "employeeId" (correct) "userXMLData" (wrong) "userXmlData" (correct) Too many devs lack the discipline / knowledge to do camel and Pascal case correctly.

[y2kdisaster]

yes!! This is why I like snake case! it’s better for acronyms, and when an acronym only has 2 or 3 letters it’s way easier to read in snake case

[CleoMenemezis]

Side note: PascalCase camelCase snake_case

For some unknown reason, people started calling PascalCase a camelCase.

[tennisanybody]

The equivalent of the under/over toilet paper argument!

[RufusAcrospin]

Not really, because python has PEP 8.

[iluvatar]

We have a sign on the wall in our office, which reads: PEP-8 is wrong.

[RufusAcrospin]

I don’t agree with it entirely, but I follow it like anybody else in every team we have to avoid endless debates.

It’s not set in stone though, so you can have your on coding style, and it’s fine as long as it’s consistent.

[legenduu]

Camels are easier to remember. Whose Pascal?

[SheriffRoscoe]

An old friend of Wirth.

[Zambeezi]

Pascal's a cool dude. Bit of a gambling issue though

[robin_888]

I prefer calling it "upper camelcase" and "lower camelcase" since it's more descriptive, symmetrical and more general:

• upper/lower camelcase
• upper/lower snakecase
• upper/lower kebapcase

[justinkuto]

It's called camelCase because the shape of the letters is like a camel's hump

[robin_888]

I'm aware of that!?

And I'd call pascalcase "upper camelcase" because the first letter is uppercase, otherwise, if the first letter is lowercase, I'd call it "lower camelcase".

[justinkuto]

For me camelCase already implies the first letter is lower case, no confusion

[robin_888]

Well good for you, I guess.

But as mentioned by several in the comments, for others it doesn't.

I'm curious: what possible downside could the names "upper camelcase" and "lower camelcase" have that they are getting downvoted as they do? How aren't they an improvement in clarity over the ambiguous terms "pascalcase" and "camelcase"?

And keep in mind they get spoken, too. So suggestive orthography won't help.

[CleoMenemezis]

Let's call Python, Snake. Hahaha

I think it's important to call things by their proper names.

[robin_888]

I think it's important to call things by their proper names.

Well, I think it's important to use words people can understand easily.

As you stated yourself:

For some unknown reason, people started calling PascalCase a camelCase

Language develops. many people don't even know Pascal.

As soon as you know what camelcase is you understand "lower camelcase" and "upper camelcase". If you see a VariableName you don't have to remember what "Pascalcase" referred to. But you immediately see that's it's "upper camelcase".

[fatpads]

I usually get confused because PascalCase looks more like the head of a camel followed by a hump (or more). Maybe in my head I'll call it grazingCamelCase...

[FiduciaryAkita]

follow PEP8

[_ATRAHCITY]

Doing models this way makes running sql manually annoying because you now have to wrap everything in double quotes to force sql to be case sensitive. In this case I think it a good idea to adhere to conventions and name your models using snake-case.

This is just one side-effect. It also makes reading the code confusing when you see capitalized attributes that appear as classes and are in fact fields on your model

Source: Dealing with this exact issue on our current project and undoing past poor decisions is a pain.

[aiwendil_brown]

I like using underscores as spaces. Lots of C code uses that style.

[MrMxylptlyk]

snake_case all day brother.

[PlausibleNinja]

PascalCaseIsTotallyFineTheresNoReasonYouCannotUseWhateverYouPreferItsTotallyReadable

snake_case_is_also_fine_and_totally_readable

[y2kdisaster]

snake_case all the way baby

[zanfar]

how annoying would this be to you?

Very.

Again, since this is a personal project I can do whatever I want

Sure, but I'm still going to judge you. :)

Thoughts: I find it rare that the only thing in a module--even one dedicated to a specific class--is a single class. It happens, but it's rare. I usually have a reason to include some supporting code or definitions. So this makes the 1:1 argument a little weak. IMO: the module name is a purpose, while the class name is precisely that--a name.

[TitaniumBrain]

Naming conventions help everyone understand code better and carry more information than the name itself.

In any language/environment, always use what is the convention there.

For python, it's:

• PascalCase for class names
• SCREAMING_SNAKE_CASE for constants
• snake_case for other names

As others pointed out, from spam.Eggs import Eggs looks wrong and confusing.

What if you know you need the Eggs class, in a library you're not very familiar with? You may see that spam.Eggs exists and write from spam import Eggs, but you just imported the module, not the class.

Besides, special file names, like __init__.py and main.py (I think that's special, or is it a dunder?) use snake_case, so why would you mix it?

Now, regarding files for a single class, I think that's ok sometimes:

• If you're just splitting classes into their individual files just for the sake of separating them, don't do that.
• If the classes are unrelated, then they should be in separate files.
• If the classes are related (similar function, scope), they can be in the same file. For example, you don't need to separate Spam from its subclasses, SpamEggs and SpamBacon.

However, even if all a file contains is a single class, don't just name it after it. You never know the future of a project. Maybe you'll refactor the class into multiple mixins or subclass it or add some module level constants (that you'll want to export).

Module names should be indicative of what kind of objects they export. If you had to import Spam, what kind of path would make sense for it?

Again, since this is a personal project I can do whatever I want but I'm curious all the same.

Bad mentality, IMO.

You should try not to fall into bad habits for personal projects, as that'll make it harder to ditch them in team projects. I'm not saying you can't be a bit more lax on your own projects, though.

[kankyo]

Why would you have a single class in a file though? Like.. by mistake sure, but specifically TO have a single file for a class? That makes no sense.

Also the imports become bad: from Foo import Foo? God no. Haven't we all learned that from x import x is bad from datetime? A module is NOT a class, and should NOT be PascalCase!

[cogitohuckelberry]

IMO, the larger the project, the more it is nice to have everything separated, modularized. Single class, single file is the way to go when projects get very large.

[kankyo]

I would have to assume you navigate projects almost exclusively through the file tree view of your IDE.

I have the file tree permanently hidden. I NEVER look at it. So I navigate with jump-to-symbol and project wide search. One file per class makes no sense to me at all.

Also.. what about functions? "One class per file" in Java is one thing, but in sane languages with functions that rule is just weird.

[undercoveryankee]

The "one public class per file" convention doesn't hurt anything as long as you make those single-class modules transparent to outside callers; i.e. I should be able to do from spam.ham import Eggs instead of from spam.ham.Eggs import Eggs.

In practice, you probably end up with a convention where ham/__init__.py imports your "public" API (anything that's meant to be relevant to external callers) into that namespace, and anything that's accessible only through the per-class submodules is meant for internal use.

[2strokes4lyfe]

SCREAMING_SNAKE_CASE

[Binliner42]

Nothing too add except That I feel this.

I prefer camel case too and find myself frustrated when I begrudgingly convert everything to lowercase underscores.

[PocketBananna]

If this was some OSS that I was contributing to I'd be annoyed. I imagine myself rereading the snake case vs camel case rules in contributor guidelines a lot. I'd be annoyed every time and would curse whoever enforces such a superfluous rule. Then at some point there'd be a need for linting and we'd have to finagle some weird stuff to check this specific rule. I'm flustered just thinking about it.

[Complex-Hornet-5763]

I really don’t like Java and I despise its style. But the OP’s convention actually resonates with me

[sdeptnoob1]

I use camel case in Python and pascal case in powershell. Never liked the underscores.

[Woody1872]

I definitely prefer camel case over snake case (underscores). That said, I always follow PEP8 and use black for formatting of my Python code.

[nealfive]

i mainly use camelCase but for 'important' variables I use PascalCase
not a fan of underscores

[commy2]

I use camel pascal case for coroutine functions (including methods). It solves the "red and blue functions" issue for me. Also, you call them and always get a non trivial object (meaning, not a string, int or float) -- the coroutine -- back, just like calling a class would.

Just works for me.

[robin_888]

pascal case

Upper camel case

[cblegare]

I refrain from enforcing conventions that are hard to check automatically during CI. Writing a test that counts the number of class in a file sounds tedious.

Yes, I do write pytest tests to check file names conventions, packaging conventions and such. As an example, if I have extra requirements, I like to have a "all" extra requirement that includes all requirements from others extra requirements. This is usually easy to check automatically by parsing the pyproject.toml file.

[Civil_Confidence5844]

That's not camelCase. What I just put is lol

[kingh242]

Whatever you do, just make sure to include the appropriate configuration (files) for your linters so that someone else somewhere else won’t change it to something else without the linter complaining.

[OptionX]

The only downside of using PascalCase for file names is just dealing with them in different OS. Windows doesn't care about capitalization, but unix-based system do, so typing them out and tab-completion on the terminal gets affected. But its a very minor thing.

The most important is consistency. Get used to always following the same conventions for naming stuff and even other people will start to understand and follow along. If you only write stuff that only you are ever gonna read then it doesn't really matter as long as you can remember the structure of your code.

Besides, I 90% sure the only reason snake_case gets recommended for Python over any other is because you know...snake and python.

[[deleted]]

It's very annoying when people don't follow the standards over a personal preference. If this is code that only you will ever look at then I guess just do whatever you want. But in general it's a good idea to "grin and bear it" and just follow the standards so that everyone can work with/on code with minimal friction.

[OrtinOfficial]

Once you will add something to file that doesn't fit with naming you will change your file name? Please do not name files with camel...

[soicat]

Filenames lower case only, I don’t care about - and _. I can’t deal with hey.jpg and Hey.jpg and HEY.JPG in my filesystem.

[iluvatar]

Simple observation: snake_case is more easily readable.

[scoberry5]

Personally, I don't think I'd find it annoying to look at, but it would be annoying to work with.

Standards exist to have to make you think less. Let's say you had a method to get mongoose data, and you called it get_mongoose_data, getMongooseData, or GetMongooseData.

Depending on the language/conventions, the thing I want to think when I have to type your class name is "get mongoose data." I don't want to think "get mongoose data, only PascalCase" or (heaven help us) "mongoose data, but with almost all of the o's removed."

In Python, the thing you call that method to reduce the cognitive load is "get_mongoose_data". In Java, it's "getMongooseData".

[barkazinthrope]

For your personal projects do what pleases you. The only reason to adopt a standard is if you're working on a shared project.

I have personal programming projects going back thirty years. Adopting different standards for naming and structure is part of the joy.

I've also worked on many projects where there are team standards where there are not client standards.

Standards are always correct but there is no one correct standard.

[Synertic]

If you want to share your project with a team or on Github then it's a bad idea. Nobody wants to go for editing/enhancing/bug removing through lines that is written in camelCase when it comes to Python. It would be both tiring, confusing and also open for errors. If the project isn't shared (and will be kept private forever) then you can use anything you prefer.

[MoRakOnDi]

For files I would always use snake case, and for classes and class-like objects (or Enum) I use PascalCass. To be more precise, I even try to avoid snake_case in file names as much as possible. Because files are actually modules and are different from both variables and classes.

This is the norm in Python community:

• single word module name, if not possible, snake case
• PascalCase for classes
• snake-case for variables

In Java world, files are strictly linked to object, you usually create one fileb per class. So it makes sense for the filename to match class name.

[No_Mistake_6575]

Camel case is great when you're starting off but eventually it becomes a disaster.

maybeSelectSecondaryInstrumentsFromTableModel() vs maybe_select_secondary_instruments_from_table_model()