I just came across this reply to a new package announcement. In it, they suggested removing underscores from function names to make them more idiomatic for Julia. [image][ANN] UpSetPlot.jl Also, I would try to rename the functions to make them more idiomatic for Julia users, e.g., without underscores. The question is, is Julia today still strictly abiding mashedcase naming? The SciML Style Guide suggested using snake_case, showing that the community and the core developers might have different opinions when it comes to function naming. In core Julia, it seems that snake_case is mainly used for internals only, but why be inconsistent? I really want to know the community’s opinion on the current state of Julia function naming, in core code vs public packages vs normal code. To me, snake_case could seem too verbose, but the readability benefits might outweigh this. Has there been a general consensus on the topic?

[image] lilachint: Has there been a general consensus on the topic? There are lots of opinions; this has been discussed several times: Naming: Remove all underscores to matter what? Recommended style guide for naming functions is not practical The least readable name in standard Julia Is there a Julia Style Guide?

There is nothing wrong with using snake_case naming in the julia package ecosystem. Things like camelCase are seen as unusual though. Julia Base itself has a self-imposed restriction that they try not to introduce any API names that are snake_case and instead use mashedcase, which is fine, but you’d be in good company if you decide you prefer snake_case, and should just ignore people complaining about it. It’s perfectly idiomatic.

From what I’ve seen, the style guide itself is quite ambiguous, unlike PEP8 which is more strict and definitive. I think it’s true that we don’t have the power to enforce anything, but having something more definitive to follow is quite less mental burden and more actual coding. I hate being too obsessed with code style! Maybe I’d just use snake_case regardless so as to reduce decision fatigue.

[image] Mason: It’s perfectly idiomatic. I disagree. If Julia Base promotes a certain code style, and the vast majority of packages sticks to it, I don’t see a very good argument to develop packages in different styles. At the end of the day, that would imply a spaghetti script with mixed code style from different packages: using A # mashedcase using B # snake_case using C # camelCase A.myfunc(B.my_const, C.otherFunc(B.other_const))

I think we won’t go as far as using camelCase for function names in Julia, mixing mashedcase and snake_case together could be bad but won’t be unhinged.

[image][ANN] UpSetPlot.jl I would try to rename the functions to make them more idiomatic for Julia users I would urge you not to use mashedcase. It is probably the worst style decisions that ever made it into Julia. The problem with mashedcase is that is does not scale: at some point, mashedcase becomes completely unreadable. Where exactly it crosses the boundary from “readable” to “I have to include some underscores” is pretty subjective. The result is that the names of functions become unpredictable. My recommendation is to leave mashedcase for Julia core, and use snake_case consistently for functions throughout the ecosystem, and CamelCase for types and modules.

Even Julia Base had public API absurdly long like require_one_based_indexing though, which uses snake_case instead of mashedcase (it was an internal until it wasn’t, but the snake_case name is kept), the inconsistency is wild.

I have a hard time getting into the mindset of finding that to be a “wild” inconsistency. At least to my eye, mashedcase and snake_case sit together side-by-side just fine, and which one I use really just depends on how clear or unclear the mashedcase version looks. Might be a quirk of my psychology, or a result of being immersed in julia’s ecosystem where the two are often freely mixed. But I really just don’t get why people get worked up over this stuff unless it becomes an actual impediment to reading (which mashedcase does become past a certain length).

[image] goerz: use snake_case consistently for functions throughout the ecosystem, and CamelCase for types and modules. I follow this for all new functions, and only if I am extending existing functions (for me also just form Base ones) I of course continue their mashed case, e.g. for isapprox. In general I prefer snake for readability. Sure if mashedcaseinlongername is still unambiguous and readable, other package developers might also stick to that, but I do not like mashed. I think to some extend they can well live side-dy-side.

I personally prefer snake_case, but I think that choosing the actual name well (and in general, good API design) is much more important than this issue. [image] juliohm: At the end of the day, that would imply a spaghetti script with mixed code style from different packages: I fail to see why that is such a big deal. If someone actually likes camelCase, but they write a great package, with a well-designed API to boot, I will just happily use it. As for mashedcase, I would not bat an eyelid.

The current state of function naming style

General Usage

stevengj April 24, 2026, 11:38am 2

There are lots of opinions; this has been discussed several times:

Naming: Remove all underscores to matter what?
Recommended style guide for naming functions is not practical
The least readable name in standard Julia
Is there a Julia Style Guide?

Topic		Replies	Views
Recommended style guide for naming functions is not practical General Usage	25	9993	February 26, 2019
Naming: Remove all underscores to matter what? General Usage	123	9292	January 28, 2018
The least readable name in standard Julia New to Julia	34	3268	May 28, 2020
Function Name Convention - General or Specific names? General Usage question	4	1024	May 21, 2020
Is there a Julia Style Guide? New to Julia question , formatting , best-practices	23	3747	April 29, 2022

The current state of function naming style

Related topics