Splitting long variable names over multiple lines

language design
1

In C, you can use the \ back slash to break a long variable name over multiple lines.

This would be useful when you want to use a descriptive variable name such as in my project, length_of_data_in_the_last_31_bytes_of_a_blob_without_consecutive_final_zeros, and have multiple indentations, and want to limit the character width to 100. Without such a use like a forward slash to break long variable names over multiple lines, the alternatives are to use shorter variable names, or to let long variable names be an exception to the 100 character wide limit.

2

I can’t even be certain that that is an intended use case of the C “feature”. It simply falls out from the fact that the C preprocessor performs a simple text-to-text transform.

I can’t imagine what the use case for such long names is? By which I mean, you might as well just write a comment at that point…

(people may counter-argue that comments can lie, but guess what? So can variable names!)

10 Likes
3

[OT] The character \ is a backslash, while / is a (forward) slash.

Re ultra-long identifiers, IME they’re cumbersome, even with autocompletion and similar aids, and I agree with @ExpHP that they’re no better than comments. In some forms of macro-generated code they can’t be avoided, but in that case they wouldn’t be visible to the user.

5 Likes
4

Personally I view names longer than e.g. 30 chars as an anti-pattern. Why?
The way I often view bindings is as a name for something else.
But if this is the case, then it follows that I need to remember that name, and be able to recall it quickly from working memory.
From this then, it follows that names too long to remember and recall like that miss their point.

4 Likes
5

At that point, you might as well petition for string literal identifiers.

$"hark gentle reader for this is the number of characters \
    (defined as single grapheme clusters, including ZWJ-joined \
    groups) contained within the most excellent variable \
    `my_string`, excluding those which fall within the 'Arabic' \
    classification" += 1;

See? You get line continuation syntax for free!

9 Likes
6

At that point you should probably pick a shorter variable name. This one is so long it's not any "descriptive", it's just annoying and downright hard to read.

(If this were a satirical proposal, I would joke that you should refactor your variable name into a function, but unfortunately I'm quite certain it isn't.)

3 Likes
7

It is true, but I saw some message like (an artificial error, demonstrate only)

error[E0369]: binary operation `+` cannot be applied to type `futures::AndThen<futures::AndThen<tokio_io::io::ReadExact<tokio_core::net::TcpStream, [u8; 1]>, tokio_io::io::ReadExact<tokio_core::net::TcpStream, std::vec::Vec<u8>>, [closure@src\client.rs:126:30: 129:14]>, std::result::Result<tokio_core::net::TcpStream, std::io::Error>, [closure@src\client.rs:129:25: 136:10]>`

before. So if it breaks into lines it would be helpful.

8

Yes, but I don’t believe changing identifier semantics is the right way to go about that. Rather, it should be on the side of error reporting where names like that are pretty-printed.

1 Like
9

How would the act of breaking up into lines something that the programmer writes in the source help with output that is formatted by the compiler? It’s already possible for the compiler to break lines in error messages if necessary, not to mention that types are usually paths, meaning that they can already be separated by whitespace, including newlines, in source as well as error messages.

10

For me, most of the information implied in the type name is useless. It should just say

 futures::AndThen<futures::AndThen<......>, [closure@src\client.rs:129:25: 136:10]>

This would be enough in most cases I think. In other words, we only need to check its first level to ensure it is the right type.

11

Yes, that is a true statement. Or at least one I agree with. However, I still don’t see any connection between it and the proposed feature. How would one’s ability to place line breaks at arbitrary places in the source affect the compiler’s (already-existing) ability to format error messages (and maybe leave out pieces of types if necessary)?

1 Like
12

Sorry I think I am a bit off topic. I only jump in for the title saying “long variable name”

13

Ah, okay. I see.

14

Thanks, I edited the comment!

15

Thanks for all the comments, fair points!

1 Like
16

Those are type names, not identifiers. Those can be split into multiple lines already.

1 Like
17

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.