# The current state of function naming style

**URL:** <https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849>\
**Category:** General Usage\
**Tags:** function, style\
**Created:** [April 24, 2026, 11:33am UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849 "2026-04-24T11:33:10Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 11:33am UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/1 "2026-04-24T11:33:10Z")

</div>

I just came across [this reply](https://discourse.julialang.org/t/ann-upsetplot-jl/136848/2) to a new package announcement. In it, they suggested removing underscores from function names to make them more idiomatic for Julia.

> [@\[ANN\] UpSetPlot.jl](https://discourse.julialang.org/t/ann-upsetplot-jl/136848/2):
>
> 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](https://docs.sciml.ai/SciMLStyle/stable/) 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?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 24, 2026, 11:38am UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/2 "2026-04-24T11:38:10Z")

</div>

> [@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?](https://discourse.julialang.org/t/naming-remove-all-underscores-to-matter-what/8549)
- [Recommended style guide for naming functions is not practical](https://discourse.julialang.org/t/recommended-style-guide-for-naming-functions-is-not-practical/21206)
- [The least readable name in standard Julia](https://discourse.julialang.org/t/the-least-readable-name-in-standard-julia/40216)
- [Is there a Julia Style Guide?](https://discourse.julialang.org/t/is-there-a-julia-style-guide/80195)

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [April 24, 2026, 11:39am UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/3 "2026-04-24T11:39:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 11:47am UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/4 "2026-04-24T11:47:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 24, 2026, 12:08pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/5 "2026-04-24T12:08:55Z")

</div>

> [@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:

```julia
using A # mashedcase
using B # snake_case
using C # camelCase

A.myfunc(B.my_const, C.otherFunc(B.other_const))

```

---

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 12:10pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/6 "2026-04-24T12:10:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [April 24, 2026, 12:11pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/7 "2026-04-24T12:11:47Z")

</div>

> [@\[ANN\] UpSetPlot.jl](https://discourse.julialang.org/t/ann-upsetplot-jl/136848/2):
>
> 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.

---

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 12:13pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/8 "2026-04-24T12:13:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [April 24, 2026, 12:17pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/9 "2026-04-24T12:17:11Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [April 24, 2026, 12:19pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/10 "2026-04-24T12:19:17Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 24, 2026, 12:19pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/11 "2026-04-24T12:19:38Z")

</div>

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.

> [@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.

---

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 12:19pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/12 "2026-04-24T12:19:44Z")

</div>

I have to agree, I believe I’m obsessing over this too much. But since I’m coming from languages that largely had consensus on naming styles, coming to Julia a few weeks ago, this definitely made me a little uncomfortable. I’m exaggerating the ‘wild’ inconsistency though, sorry for that.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [April 24, 2026, 12:22pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/13 "2026-04-24T12:22:20Z")

</div>

As a potentially helpful historical note, (that I might be misremembering), one reason that Base sets the `mashedcase` rule for itself was that they felt that for a **Base** language API, it would be a code-smell to have overly long, complicated, descriptive names.

A base API should be a common _base_ of shared idiots that forms the language, and so they should be commonly recognized idioms, and relatively simple concepts. So using `mashedcase` forced the language API to choose shorter simpler names.

Packages are not the same. They are often for niche concepts, and are not providing concepts that everyone should be expected to know ahead of time in order to use the language. Therefore there are many cases where `longer_more_descriptive_names` are appropriate, and for that, `snake_case` just is a better fit.

---

<div class="post-metadata">

**Author:** ![lilachint](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@lilachint](https://discourse.julialang.org/u/lilachint)\
**Post date:** [April 24, 2026, 12:23pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/14 "2026-04-24T12:23:38Z")

</div>

Fair enough, the core developers’ decision rationales are good to know! I love the summary of the situation.

> [@Mason](#):
>
> A base API should be a common _base_ of shared idiots that forms the language

I’m sorry but that typo is quite funny. xD

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [April 24, 2026, 12:24pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/15 "2026-04-24T12:24:54Z")

</div>

lol, looks like I’m the shared idiot today. I’ll leave the typo up.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [April 24, 2026, 12:51pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/16 "2026-04-24T12:51:48Z")

</div>

> [@Mason](#):
>
> Therefore there are many cases where `longer_more_descriptive_names` are appropriate, and for that, `snake_case` just is a better fit.

Yeah, I had a time where I did not like that one of my packages had ( and still has) `isapprox` and `is_point` – but by now I made my peace with that, exactly because I am fine with Base names being mashed and “mine” being snake.

---

<div class="post-metadata">

**Author:** ![RaulDurand](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rauldurand/32/2044_2.png) [@RaulDurand](https://discourse.julialang.org/u/RaulDurand)\
**Post date:** [April 30, 2026, 3:43pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/17 "2026-04-30T15:43:11Z")

</div>

Beyond camelCase and snake\_case, still on naming conventions, I find the use of a bang `!` at the end of mutating function names quite odd.

- It’s not familiar to people coming from other languages (specially because `!` is often not even allowed in names)
- It does not specify what is mutating
- it looks awkward when combined with the negation operator.
- Sometimes it makes difficult to find function names depending on the tools, e.g. regex

Personally, I prefer more explicit names using `add_`, `set_`, `_inplace`, etc., (without the bang), and I also make the mutating behavior clear in the documentation.

In this context, many Julia functions would not even need a bang, e.g. `push!`, `pop!`, `append!`, `delete!`, `setindex!`, `insert!`, etc., where the bang arguably worsens readability.

Other functions like `sort!`, `map!` would be `sort_inplace`, `map_inplace` or `apply_map` etc., which is very idiomatic.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 30, 2026, 3:58pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/18 "2026-04-30T15:58:09Z")

</div>

That’s the Julia idiom I like the best! A name ending with `_inplace` also doesn’t specify what is mutating, and the existence of a `!` certainly shouldn’t stand alone without documentation of what is happening.

It’s not something semantically meaningful to the language — it’s just a hint to humans that there’s some mutation happening. And I’m almost always grateful to get that hint.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 30, 2026, 3:58pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/19 "2026-04-30T15:58:39Z")

</div>

> [@RaulDurand](#):
>
> It’s not familiar to people coming from other languages (specially because `!` is often not even allowed in names)

…unless you’re familiar with Lisp, Scheme, or Ruby, which use the same convention.

You’re right that you need to check the docs to be sure what is mutated, though it’s almost always the first argument. But knowing that a function call has side effects makes it much easier to reason about what code is doing. And very often functions have mutating and non-mutating variants, so it’s good to have a simple convention to distinguish them.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 30, 2026, 4:17pm UTC](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849/20 "2026-04-30T16:17:15Z")

</div>

I usually avoid underscores in function names by designing APIs that are made of simple verbs and structs that hold complex state (and name).

Instead of writing `required_action_to_take(args...)` like in C, I take this long name as a sign that the software design can be improved. I introduce auxiliary structs to hold state `ComplexMethodInCamelCase` and a simple short verb (e.g., `perform`) to execute:

```julia
method1 = ComplexMethodInCamelCase(...)
method2 = AnotherComplexMethodToConsider(...)

perform(args..., method1)
perform(args..., method2)

```

I’ve been doing this across all the packages I maintain, and never encountered a single instance where snake\_case was necessary to improve clarity. I feel that snake\_case is basically a consequence of using Julia with little to no abstraction.

[Next page](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849.md?page=2)