Looking over the latest 1.0 milestone I see that the underscore apocalypse in Base is beginning to build steam. Am I correct in thinking that julia now wants everything to just be mashed together? Length doesn’t seem to be a real issue anymore as we have beginindex and nbytesavailable coming. I increasingly find names in julia really hard to read, and am resigning myself to have to get used to it, and update my own code so it at least feels consistent. Is this how the rest of the ecosystem is going? I haven’t checked in a while. The aesthetics of 1.0 is bumming me out, going to be a lot of using and weird names :frowning:

[image] kristoffer.carlsson: You can. Oh that makes me so happy! :smile:

Thanks so much for this. I think at times I struggle with understanding the changes that happen in Github, but this makes a lot more sense to me now. Looking at that list of possible imports is far less scary then I had made in my mind! I still want more _ but I feel less like the choices are being made in an arbitrary way just to remove spaces between words :slight_smile:

Removing underscores represents an aesthetic preference that, to the decision-makers, is more important than readability. My approach is to use underscores except when there is a direct analogue in Base (like the is* functions).

[image] iamed2: is more important than readability. I dispute whether this is really the case. I certainly agree that you wouldn’t want stuff like besselfunctionofthesecondkind(a, x), but there’s nothing in Base that looks like that, which is the whole point. Multiple dispatch is particularly conducive to short function names hence the huge library of methods in Base the vast majority of which are no more than 2 words. I agree that particularly verbose function names, when necessary, should have underscores.

I do not understand why the Julia core team decided to sacrifice readability for beauty. Beautiful code is important for me, but not to seperate words either with camel case or with underscores sacrifices readability. I don’t understand this decision. :cry:

[image] StefanKarpinski: As a matter of historical interest, there was a period of time where sticking code into the JuliaLang/julia contrib directory was how packages were developed. OT X-ref for the interested: Run the half-life of code analysis on Julia? - #2 by cdsousa

[image] iamed2: Removing underscores represents an aesthetic preference that, to the decision-makers, is more important than readability. I look at it differently. I don’t think it reflects a preference for mashing words together – instead it is a convention that encourages you to consider how you name identifiers in your code, and, more generally, how you organize the concepts you’re working with. Strive to choose concise names, not too short, not too long. If you need underscores, it most likely means that you can work harder to find a better name, or perhaps that you are mixing together two concepts that should be separated. It reminds me about the principle (which has been mentioned many times) of implementing as much of the Julia language in Julia itself, even when dropping down to C or something else would be easier and more efficient. It sounds like a potential handicap, Julia could be faster with more C code in it, but in the long run it’s better. Analogously, discouraging underscores forces you to work harder and do better. [image] ufechner7: I do not understand why the Julia core team decided to sacrifice readability for beauty. Beautiful code is important for me, but not to seperate words either with camel case or with underscores sacrifices readability. I don’t understand this decision. :cry: I think that if you stick to the convention, and put in the extra work, your code will in the end be more readable.

I don’t think that ANY language can become more readable by ommiting spaces and by putting everything in one word. In science, you have subscripts and superscripts. You don’t write everything in one word. While programming, to have at least subscripts (by using an underscore) is essential for me. Nothing improves if you remove this degree of freedom.

I don’t think anyone forces you not to name your own functions however you like. I hope this helps?

But that’s the point. Don’t put everything in one word. In science, you have single-letter identifiers, mostly. You need a lot of subscripts to make up for that.

Naming: Remove all underscores to matter what?

General Usage

mauro3 January 23, 2018, 8:38pm 11

OT X-ref for the interested: Run the half-life of code analysis on Julia? - #2 by cdsousa

Topic		Replies	Views
Recommended style guide for naming functions is not practical General Usage	25	10010	February 26, 2019
Which names are hard to read? Community	15	2292	March 9, 2017
The current state of function naming style General Usage function , style	24	1511	May 2, 2026
Unicode: a bad idea, in general General Usage	83	5945	June 17, 2023
Abbreviations in source Internals & Design	32	3301	April 20, 2019

Naming: Remove all underscores to matter what?

Related topics