# 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:** 1\
**Showing post:** 20

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

---

_[View the full topic](https://discourse.julialang.org/t/the-current-state-of-function-naming-style/136849)._