5 ms·
I agree with everything you say but want to add a caveat to the "long descriptive names". I find that there must be a balance where names are clear and unique e
by jstimpfle 4y ago
I agree with everything you say but want to add a caveat to the "long descriptive names". I find that there must be a balance where names are clear and unique enough while not tiring the eyes too much by making them read long boring repetitive prefixes all the time. There is a fine art to creating words and also sentences (statements).
By now if a "module prefix" is bigger than say 4-5 characters, I get unhappy and know I need to improve, to find a short mnemnonic. Same goes for local variables names, which I try keep at 1-5, rarely they get 10+ characters long. There is always this tension between names being "self-documenting" and "just long enough to remind of the purpose that was explained in a not too distant context". Variables that are frequently used should be shorter. Variables that have a clear intuitive use (like "x" or "i" which most often have very clear meaning with only little context added) should be shorter. Module names should _always_ be very short because (I assume) there are only few modules, and it's better to remember the purposes of a few modules together with their abbreviated names, than to have to read a long repetitive module name each other line. Function name suffixes (without the module prefix) should often be long because there are many different functions and not all of them can be cached with their meanings in the programmer brain - so I allow function names to be a little self-documenting typically.
I agree that the names in POSIX and C are too short and cryptic but think they made more sense in the context of Unixes of the 1970s when projects weren't as big as today.
I still try to stay within 80 or 100 columns because line length a readability / eye strain concern as well, but given that I'm in the 8 spaces camp I don't freak out anymore if there is the occasional 140 characters line and I'm to lazy to trim it down. Judicious insertion of linebreaks is most often useless busywork. Then again, some function signatures take too many arguments (glVertexAttribPointer/glBufferData... or the Win32 API come to mind) and inserting linebreaks in calls can improve readability sometimes.
- AlbertoGP 4y ago> “I find that there must be a balance where names are clear and unique enough while not tiring the eyes too much by making them read long boring repetitive prefixes all the time.” I have that problem, repetitive prefixes getting in the way of reading the code, and I’ve been doing some experiments with what could be described as “local namespacing”, only inside an expression or statement, with the prefix/suffix feature of the backstitch macro in my C preprocessor: https://sentido-labs.com/en/library/cedro/202106171400/#backstitch-macro https://sentido-labs.com/en/library/cedro/202106171400/#back... For instance, writing a program with libxml2, I write: Next(reader) @xmlTextReader...; which gets translated to xmlTextReaderNext(reader); and I find the first easier to read. Whether that’s the case for others, I don’t know. A longer example from the link I wrote above, this time for libuv: @uv_thread_... t hare_id, t tortoise_id, create(&hare_id, hare, &tracklen), create(&tortoise_id, tortoise, &tracklen), join(&hare_id), join(&tortoise_id); Result: uv_thread_t hare_id; uv_thread_t tortoise_id; uv_thread_create(&hare_id, hare, &tracklen); uv_thread_create(&tortoise_id, tortoise, &tracklen); uv_thread_join(&hare_id); uv_thread_join(&tortoise_id);