So I have a somewhat obsessive need to use full words instead of abbreviations when I code. I think it really helps public library code to be readable and self-documenting. I was thinking today that I would have fun going through the JuliaLang/julia and replacing all abbreviations with full words. Of course, I wouldn’t change any part of the public API, just internal code. But I didn’t want to waste my time if no one would accept a PR, so I wanted to explore the idea here first?

The Linux Kernel also does not accept patches in which only the names of things are changed [image] Code Refactoring Code refactoring should not be done just because we can. There are a number of “refactoring” tickets that have been opened over time, such as suggestions to rename long-standing functions or confor… although, they might have changed their policy with their new code of conduct

The julia source seems heavily abbreviated to me, with most internal names being just one or two letters. I’m pretty sure Google wouldn’t approve.

No all abbreviations are bad, a lot depends on context. In simple cases, when they are perfectly understandable, abbreviations should be fine. Even if some existing code should benefit from expansion, it may be better to just leave it alone and wait for some substantial reason that requires touching that code, and then improve on style if necessary. Someone needs to review these PRs, and pure coding style improvements (which are often in the eye of the beholder) may not be an efficient use of their time. Also, if there are no explicit violations of a specific coding style, it may be fine to assume that the person who wrote some code and got it accepted as a PR is an experienced programmer who knew what he/she was doing. You may do some things differently, but that alone might not be a good reason for a PR. Finally, I think it is great if you have time for contributing to Base and the standard libraries with an eye to small details. There are many minor open issues that could benefit from your work.

Related topic [image] Variable name style General Usage What’s your opinion? I tend to like single-letter variable names e.g. i, j, k for indices, w, h for width and height, s for any string, t for time, etc. Sometimes when I use meaningful / long names, I end up masking an existing function unintentionally (like sum) and then I would end up scratching my head why sum doesn’t work anymore… It would be hard to change the style completely for a large project like Julia. If we do it partially then it becomes too inconsistent to be useful. Also, existing contributors will probably finding it unpleasant (as seen above).

When we take Google as an authority, we should also consider the fact that Go has different style for variable names: Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount . Prefer i to sliceIndex . The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter ( i , r ). More unusual things and global variables need more descriptive names. Source: CodeReviewComments · golang/go Wiki · GitHub

Well, I specifically had to ask what, e.g., ptls stood for. A few longer words would definitely help

Pointer to thread local storage. There’s no way you’ll put this full name in. It’s not user facing and is not particularly well documented in the code and you are very welcome to add those comments around where it’s declaration in the header tls.h. A long version of the doc can be found in the definition in threading.c.

I put my vote for a_variable_representing_pointer_to_thread_local_storage :grin:

TLS is a domain-standard abbreviation. ptls is not, however. If we’re nit picking on the names, I would suggest ptr_tls. [image] simonschoelly: When we take Google as an authority I wouldn’t suggest that Google has any authority over Julia coding style (nor do I speak for Google in any capacity). I would argue, however, that it would be beneficial for the Julia core developers and the broader community to converge on style guidelines and enforce them with some consistency. Existing style guidelines from an array of communities could be useful to draw from. As a Google employee I have some experience interpreting the Google style guides, so they’re the first that come to mind as an example. In the JuMP style guide we’ve stated its motivations as: conveying best practices for writing readable and maintainable code reducing the amount of time spent on bike-shedding by establishing basic naming and formatting conventions lowering the barrier for new contributors by codifying the existing practices (e.g., you can be more confident your code will pass review if you follow the style guide) We’ve had a JuMP style guide for about a year, and I’d say it’s been relatively successful at meeting these goals. It saves a lot of time when reviewing PRs if I can point to a link in the style guide. People are generally happy to follow conventions if you’ve written them down clearly.

Abbreviations in source

Internals & Design

bramtayl April 14, 2019, 10:24pm 21

pointer_to_local_storage seems fine?

Topic		Replies	Views
Naming: Remove all underscores to matter what? General Usage	123	9292	January 28, 2018
Kate Gregory “Naming is Hard: Let's Do Better” and what lesson we can learn from it Teaching & Outreach discussion	34	2836	January 8, 2024
Digression on short variable names Offtopic	33	2076	December 25, 2022
Package naming guidelines Community	57	6210	January 11, 2026
Recommended style guide for naming functions is not practical General Usage	25	9993	February 26, 2019

Abbreviations in source

Related topics