Snake case

Brainstorming
1

Since I abondoned my job languages Delphi and C# and using Rust for a while I have become a fan of snake case.

I wish I could scientifically prove that

doSomethingComplicated

is more difficult on the eyes and more difficult to process for the brain than

do_something_complicated
2

I wish zig adopted Pascal_Snake_Case for structs and and functions that return generic structs. So that we can have normal snake_case for variables and regular functions.

3

I sometimes do stuff that generates code, and it’s much simpler to go from e.g. “some_thing” to “get_some_thing” than “someThing” to “getSomeThing”. Especially in macros (in other languages) or comptime stuff. :slight_smile:

4

… Pascal_Snake_Case

That’s basically the worst of both conventions combined :wink:

FWIW I mostly use snake_case in C projects with everything lower-case except PREPROCESSOR_MACROS. Types get the _t postfix instead so that they don’t collide with other names.

In TS and Zig I use the camelCase vs PascalCase convention (also perfectly fine).

3 Likes
5

Although this might be bikeshedding, I’m still curious why.

Even though this style may not be very efficient to type, if we follow the principle of “code readers over code writers”, I think it is quite pleasant to read.

Oh! I always thought that identifiers ending with _t are reserved identifiers in POSIX, so I would deliberately avoid using them.

6

Too much “typing complexity”, you have two characters side by side which require pressing the shift key, which is unusual. Also in the middle of a string both _ and uppercase character combined is redundant for separating ‘words’, one of those is sufficient.

Also I think it looks ugly :wink: (I could probably live with This_is_a_type - no idea what this convention is called though).

Oh! I always thought that identifiers ending with _t are reserved identifiers in POSIX

True, so just don’t name your own types like POSIX types, problem solved :slight_smile: And if you’re not talking to the POSIX APIs (e.g. the C standard and POSIX are entirely separate things) POSIX conventions are irrelevant anyway.

7

Ikr, I’ve never seen any popular projects adopt to that case, it helps with niche cases like UTF8String, here you know UTF8 is a sperate thing but think about some other abbreviations you’re not familiar with, with Pascal_Snake_Case it would be UTF8_String, it’s clear String is a seperate thing, UTF8 is another seperate thing and since the words are started with capital word we can infer easily it’s a type.

1 Like
8

I’m sorry i know this doesn’t bring anything meaningful to the conversation or elevate the debate, but :face_vomiting:

1 Like
9

I was just looking through the binding generators for the sokol-headers, and Odin seems to use this Pascal_Snake_Case convention for types (apparently it’s called Ada_Case).

Also see: Naming and style convention ¡ odin-lang/examples Wiki ¡ GitHub

1 Like
10

And I just wish more people would follow the Zig std’s (and for most of the Zig ecosystem’s) code style when writing Zig so that I don’t have to have a mix of conflicting styles in a single project. Looking at you, microzig.

This topic has already been discussed to death, and it’s not changing. As per andrewrk:

Closing again. I toyed with this in GitHub - andrewrk/autodoc: Zig Documentation Generator ¡ GitHub and found it to tend to cause unfortunate shadowing that was not really the case before. camelCase for function names I think is serving us fairly well.

That said, it’s just what we’re going to do in the standard library - individual projects can obviously do their own naming conventions. And sometimes projects doing their own naming conventions can be handy in its own way, the human understands that one area of code has this vibe, another has that one.

I’ll also consider changing the naming conventions of builtin functions. For whatever reason, camelCase in builtin functions just feels wrong. I often mistype @typeInfo and @TypeOf in particular.

2 Likes
11

Just as a historical note, the venerable ACE C++ libraries used Pascal_Snake_Case, for readability and for ease of moving the cursor over each separate word. Even if it was not my preferred style, I always respected the fact that they had a real, practical argument for their choice.

12

I’ve always associated with Ada.

13

(post deleted by author)

14

I likewise came from a C# background, and thought that Pascal/Camel-case were superior, even abandoning my beginner Ruby roots which uses snake case for most function and variable names.

To be honest, I disliked Zig’s naming conventions when I first started using it. At the time, I had some rough outline of an idea that there were too many different case-conventions being mixed together, though if I was being honest with myself, the reason was that I simply didn’t like it for aesthetic reasons and being different than what I most often used.

I have since come to really like and appreciate it, and recognize the benefit of having different styles for the common distinctions in the grammar. Maybe it is just my eyes getting older and me getting set in it my ways, but I have also grown to like snake_case for the common identifiers that I must read the most.

Your topic actually sparked some interest and I wondered about it. I figured that there have been many studies done on this over the years. To my complete non-surprise, none of them agree with each other, and they all reach different conclusions, regardless of which methodology or metric is used. There are some obvious agreements what is “bad”, but as far as snake_case vs camelCase, the jury is still deliberating, and likely still will be long after we are gone.

I did find a helpful article that linked to many different studies as its citations. It will make it easier for us to each pick the study that proves are preferred style is the correct one.

Also vim is better than emacs, and there is One True Brace Style. :smiling_face_with_sunglasses:

5 Likes
15

I am happy if people just use their own style. as long as it is kinda logical and readable and consistent.
In C# I started using snake case just because it conflicted with the standard conventions: easy to distinguish my own things.

2 Likes
16

any style is better than Hungarian Notation

LPBYTE    lpbDataBuffer;
DWORD     dwcbDataBufferSize;
BOOL      fDataBufferAllocated;
LPCTSTR   lpcszComputerName;
LPDWORD   lpdwcbTotalBytesRead;
LPLPLPSTR lplplpszNames;
17

That’s just Systems Hungarian which is, in todays age of LSPs and good developer tooling, indeed a quite foolish and, so I think, stupid idea.

But I do like the notion of Apps Hungarian Notation where you encode Semantic meaning about the variable into it. I quite like this post which is a bit longer but gets the point across.

On the topic on style in Zig I would really like everybody to just use the one outlined in the language reference because then you can just easily read “foreign” code. camelCase vs snake_case vs PascalCase doesn’t really matter in the game scheme of things, but having one true consistent style for a language is indeed nice. Just look at all the different ways how people format their C. If I may say so: no your project or code isn’t so special that you should disregard the, hopefully soon, standard for Zig.

1 Like
18

I used to care. I don’t know if a little age has eroded my sense of style or sharpened my ability to read “anything” at about the same speed… but I just don’t care any more, as long as there’s some consistency within the language, and, for a project, if it adopts its own, as long as it’s relatively self-consistent.

“Do yuo fnid tihs smilpe to raed?” I think that’s one of the better-known “missing letter effect” examples; we can do a lot with a little, if we focus on the meat.

1 Like