[qouteall]

With modern IDE and AI there is no need to save letters in identifier (unless too long). It should be "sizeInBytes" instead of "size". It should be "byteOffset" "elementOffset" instead of "offset".

[pveierland]

When correctness is important I much prefer having strong types for most primitives, such that the name is focused on describing semantics of the use, and the type on how it is represented:

    struct FileNode {
        parent: NodeIndex<FileNode>,
        content_header_offset: ByteOffset,
        file_size: ByteCount,
    }

Where `parent` can then only be used to index a container of `FileNode` values via the `std::ops::Index` trait.

Strong typing of primitives also help prevent bugs like mixing up parameter ordering etc.

[kqr]

I agree. Including the unit in the name is a form of Hungarian notation; useful when the language doesn't support defining custom types, but looks a little silly otherwise.

[canucker2016]

Depends on what variant of Hungarian you're talking about.

There's Systems Hungarian as used in the Windows header files or Apps Hungarian as used in the Apps division at Microsoft. For Apps Hungarian, see the following URL for a reference - https://idleloop.com/hungarian/

For Apps Hungarian, the variable incorporates the type as well as the intent of the variable - in the Apps Hungarian link from above, these are called qualifiers.

so for the grandparent example, rewritten in C, would be something like:

    struct FileNode {
        FileNode *pfnParent;
        DWORD ibHdrContent;
        DWORD cb;
    }

For Apps Hungarian, one would know that the ibHdrContent and cb fields are the same type 'b'. ib represents an index/offset in bytes - HdrContent is just descriptive, while cb is a count of bytes. The pfnParent field is a pointer to a fn-type with name Parent.

One wouldn't mix an ib with a pfn since the base types don't match (b != fn). But you could mix ibHdrContent and cb since the base types match and presumably in this small struct, they refer to index/offset and count for the FileNode. You'd have only one cb for the FileNode but possibly one or more ibXXXX-related fields if you needed to keep track of that many indices/offsets.

[groundzeros2015]

Long names become burdensome to read when they are used frequently in the same context

[ivanjermakov]

When the same name is used a thousand times in a codebase, shorter names start to make sense. See aviation manuals or business documentation, how abbreviation-dense they are.

[layer8]

When you’re juggling inputBufferSizeInBytes, outputBufferSizeInBytes, intermediateRepresentationBufferSizeInBytes, it becomes unwieldy and cumbersome.

I once had a coworker like that, whose identifiers often stretched into the 30-50 characters range.You really don’t want that.

[throwaway2027]

Isn't that more tokens though?

[post-it]

Only until they develop some kind of pre-AI minifier and sourcemap tool.

[0x457]

Sure you get one or two word extra worth of tokens, but you save a lot more compute and time figuring what exactly this offset is.

[Onavo]

Not significantly, it's one word.

[meindnoch]

Tokens are not words.

[Onavo]

Relatively, they are the same, depends if it's word level.