<div dir="ltr"><div dir="ltr">Am So., 20. Sept. 2020 um 14:20 Uhr schrieb MigMit <<a href="mailto:migmit@gmail.com">migmit@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] there are lots of places where long identifiers are distracting. Sometimes they make sense, but a lot of times they just don't.<br></blockquote><div><br></div><div>I think a good rule of thumb is: The length of an identifier should be proportional to the size of the scope in which it is valid.</div><div><br></div><div>As an example: If you design an API, names like "openBinaryFile", "handleValidationError", "primaryDrawingContext" are a good idea. If you have a simple 1-line or 2-line helper function, one-letter names can make things vastly more readable, because you can see the "meat" of the code more easily without drowning in 20-letter identifiers spilled over 5 lines. So just using "ctx" or even "c" for "primaryDrawingContext" in a one-liner can improve things. This is even more true when you have a type annotation with long, descriptive type names for this function.</div><div><br></div><div>But all of this is very subjective, and in the end writing good, readable code is a bit of an art. There are guidelines and tips on how to do this, but there can never be hard and fast rules which will make everybody happy.</div></div></div>