4 ms·

> The best code is code written by a talented programmer who can make the code readable to All people of All skill levels. Unfortunately this is not true. Code

> The best code is code written by a talented programmer who can make the code readable to All people of All skill levels. Unfortunately this is not true. Code is like language. You can make it readable for everyone by using the most easy to comprehend and least ambiguous language. But doing so decreases efficiency for both "advanced" writers and readers. "Advanced" grammar and vocabulary exists for a reason - it allows to express thoughts more succinct and concise and can decrease the time to understand something in great level of detail and context by magnitudes. But it requires knowledge and shared context between writer and reader. It's the same for using a very efficient compression algorithm vs. plaintext. You cannot have the advantages of both at the same time. Pick your poison. (I assume you understand "pick your poison", a non-native reader might not. It's so nice and concise, isn't it? :)

moonchild 6y ago
As another example, consider the simple wikipedia[1]. It undeniably serves a very important role. Would it be appropriate for it to replace the standard english wikipedia? Or, would it be appropriate for all scientific literature to be written in the style of simple wikipedia? Simplicity and accessibility are undeniably important. But they shouldn't be your only goals. 1. https://simple.wikipedia.org/wiki/Main_Page https://simple.wikipedia.org/wiki/Main_Page
nendroid 6y ago
Unfortunately for your argument, it actually is completely true. You're thinking about it the wrong way, an analogy to english doesn't prove your point when the analogy is irrelevant. Sure there's advanced vocabulary in English. But within that domain the english is still understandable. If the reader understands the domain he understands what is written and does not need to decipher or decode what is written. The domain expert just reads it and gets it, no deciphering needed. This is not what happens with domain specific code and this is not how domain experts read code therefore your analogy does not apply. Reading code tends to be very very different from reading english and much much slower. Reading is actually an inaccurate term. The reader for code spends much of his time deciphering code and any name that helps elucidate context and eliminate deciphering is a plus. This occurs EVEN for domain specific code. What happens with domain specific code is that a programmer tends to make up abbreviations on the fly and ends up writing something that is not readable at first glance and the reader needs to decipher the code. For example let's say I'm a domain expert in robotics and I want to encode positioning of the robot. For elegance I use this: xPosRelB = 23 which is short for x position relative to base. versus meters_west_from_base = 23 I can assure you 95% of programmers write the former rather than the latter and it's definitely not for efficiency gains. You might lose like 1 nanosecond of efficiency reading the latter but this only applies if you already know the meaning of xPosRelB, seriously if every single variable was written in the same way as the former you LOSE efficiency from trying to decipher meaning from context. The end result is that in order to figure out what xPosRelB is the reader always has to sort of dig a bit at the context. He has to see how it's used, where that variable comes from or in other words he needs to "decipher" it. This is super common in programming but not very common when reading English. Again your analogy does not apply. In short the second name in the example is just read and understood and is by far the better choice. When you ask the average programmer why he wrote xPosRelB rather than meters_west_from_base, he'll tell you that meters_from_base is too long and too ugly. Programmers bitch and moan about stuff like this that doesn't even matter. I had one guy tell me that you shouldn't mix and match camel_case or snakeCase because it just looks bad (there's a real reason why people don't mix it, and it's not aesthetics). If I go meta and bring this topic up and ask the programmer why again.... then he brings up reading efficiency, exactly what you're doing here. Readability and structure is what's important not aesthetics. What matters is that someone can read your code rather than decipher it. Length and prettiness contribute nothing to readability and barely dents reading efficiency. Domain targeted programming is stuff like this: gallonsOfCompoundV = 34 Compound V is the domain. There's no need to explain what compound V is in the variable name. This is not a big problem with coding for readability. The big problem and the problem I am addressing is this: compVg = 34 Seriously. Someone once complained to me about the word "Of" in my variable name. My bad, I'm sorry that added 2 nanoseconds to your reading time with the word "of". Of course the team may have conventions. For example my team prefixes the letter k to all constants. This stuff is fine and doesn't harm readability, but this is not what I'm talking about.

moonchild 6y ago

As another example, consider the simple wikipedia[1]. It undeniably serves a very important role. Would it be appropriate for it to replace the standard english wikipedia? Or, would it be appropriate for all scientific literature to be written in the style of simple wikipedia? Simplicity and accessibility are undeniably important. But they shouldn't be your only goals. 1. https://simple.wikipedia.org/wiki/Main_Page https://simple.wikipedia.org/wiki/Main_Page

nendroid 6y ago

Unfortunately for your argument, it actually is completely true. You're thinking about it the wrong way, an analogy to english doesn't prove your point when the analogy is irrelevant. Sure there's advanced vocabulary in English. But within that domain the english is still understandable. If the reader understands the domain he understands what is written and does not need to decipher or decode what is written. The domain expert just reads it and gets it, no deciphering needed. This is not what happens with domain specific code and this is not how domain experts read code therefore your analogy does not apply. Reading code tends to be very very different from reading english and much much slower. Reading is actually an inaccurate term. The reader for code spends much of his time deciphering code and any name that helps elucidate context and eliminate deciphering is a plus. This occurs EVEN for domain specific code. What happens with domain specific code is that a programmer tends to make up abbreviations on the fly and ends up writing something that is not readable at first glance and the reader needs to decipher the code. For example let's say I'm a domain expert in robotics and I want to encode positioning of the robot. For elegance I use this: xPosRelB = 23 which is short for x position relative to base. versus meters_west_from_base = 23 I can assure you 95% of programmers write the former rather than the latter and it's definitely not for efficiency gains. You might lose like 1 nanosecond of efficiency reading the latter but this only applies if you already know the meaning of xPosRelB, seriously if every single variable was written in the same way as the former you LOSE efficiency from trying to decipher meaning from context. The end result is that in order to figure out what xPosRelB is the reader always has to sort of dig a bit at the context. He has to see how it's used, where that variable comes from or in other words he needs to "decipher" it. This is super common in programming but not very common when reading English. Again your analogy does not apply. In short the second name in the example is just read and understood and is by far the better choice. When you ask the average programmer why he wrote xPosRelB rather than meters_west_from_base, he'll tell you that meters_from_base is too long and too ugly. Programmers bitch and moan about stuff like this that doesn't even matter. I had one guy tell me that you shouldn't mix and match camel_case or snakeCase because it just looks bad (there's a real reason why people don't mix it, and it's not aesthetics). If I go meta and bring this topic up and ask the programmer why again.... then he brings up reading efficiency, exactly what you're doing here. Readability and structure is what's important not aesthetics. What matters is that someone can read your code rather than decipher it. Length and prettiness contribute nothing to readability and barely dents reading efficiency. Domain targeted programming is stuff like this: gallonsOfCompoundV = 34 Compound V is the domain. There's no need to explain what compound V is in the variable name. This is not a big problem with coding for readability. The big problem and the problem I am addressing is this: compVg = 34 Seriously. Someone once complained to me about the word "Of" in my variable name. My bad, I'm sorry that added 2 nanoseconds to your reading time with the word "of". Of course the team may have conventions. For example my team prefixes the letter k to all constants. This stuff is fine and doesn't harm readability, but this is not what I'm talking about.