5 ms·

Great post. This is one of my biggest pet peeves with Ruby and languages like it; they encourage developers to "show off" by using the most esoteric features th

Great post. This is one of my biggest pet peeves with Ruby and languages like it; they encourage developers to "show off" by using the most esoteric features they can find (even better if these features use weird symbols). Compared to a language like Python that has few neuroses, the same developer writes much less readable code. The post may have been better if the author included a Python sample that does the same thing: long_string = 'ajix mxozl xoap' new_string = [] for word in long_string.split(' '): new_string.append("{}{}".format(word[0].upper(), word[1:])) new_string = ''.join(new_string) Admittedly there are a few annoying symbols in here, mostly due to the non-intuitive operation of the join function and the well-meaning but less-than-ideal string formatting syntax (which could've been avoided if we used conventional strong concatenation, and which PEP 0498 attempts to improve). Also admittedly, coders who want to show how smart they are would try to use a list comprehension to do this, which is slightly less readable and imo shouldn't be used over this format without a good reason. But it's still much easier to parse than the Ruby version because everything is explicitly spelled out in the loop, and you generally shouldn't have to consult the language docs to look up 4 different rarely-seen operators. Remember, debugging is twice as hard as authoring, so if you write the most clever code possible, you are by definition not intelligent enough to debug it. ;) I understand that people can't be expected to stick to that on their own, so they need languages that promote function, uniformity, and ease of use over showmanship. The simplicity of the code is one of the main things I look for in interviews. If you could've done something with the conventional, simple language construct that doesn't require someone to go back and refer to the docs, even if it takes more lines, but instead you used the super-arcane construct to prove how well you know the language or to "get it all on one line", I'm going to look on that pretty dubiously. The last thing I want to deal with on my projects is the residue of someone's ego impacting our ability to read their code and get things done quickly and easily. P.S., in Python, there are a couple of shortcut functions for capitalizing each word in a sentence: str.title() and str.capwords().

neilparikh 11y ago
Something like the following: capitalize = lambda word: "{}{}".format(word[0].upper(), word[1:]) new_string = ' '.join(map(capitalize, long_string.split(' '))) or: new_string = ' '.join(["{}{}".format(word[0].upper(), word[1:]) for word in long_string.split(' ')]) is much clearer and simpler to me, because it explains the intention of the code: split the string into words, map each word to it's capitalized version, then join it again. With the loop, I have to mentally "run" the code to realize that the for loop and append are to go through the split version and add the converted words to a new list. Obviously, this is a pretty subjective topic, and which version you prefer will depend what you're familiar with/the languages you use.
- cookiecaper 11y ago
  For me, readability is about how intuitive something is, how much can be understood with basic knowledge of programming in general and perhaps a quick primer on the specific language. I think this is the best measurement because it emphasizes a reliance on the most commonly used, general concepts, and encourages people to use those unless there's a good reason not to. A side benefit is that the more basic language primitives and flow controls tend to be more performant, better tested, and have fewer weird edge cases where they behave in an unexpected manner. I dislike your first example because a) imo, the lack of spacing makes it harder to see what's going on. it's more obvious that something is being iterated in a for loop with a new indentation level than in the map function. b) it depends on the Python-specific implementation of lambda. The behavior of a lambda varies substantially from language to language and lambdas are used rarely enough that it's pretty likely someone who doesn't spend all day every day in Python is going to have to go back and look up the specific behavior. The syntax is much less clear than a full function definition. In my opinion, it's much easier to read code like: def capitalize(str): return "{}{}".format(str[0].upper(), str[1:]) for word in long_string.split(' '): captizalize(word) ... This makes it much more obvious what's going on, and it should be readable to anyone with a passing knowledge of Python, and possibly anyone with a knowledge of programming languages in general. Invocation of map and lambda in this case only make the intent of the program more obscure. I'm not saying that map or lambda are never appropriate to use; sometimes they are. But I don't think it's wise to use them when more basic, universal language constructs do an equally adequate job, especially if the only benefit is "fewer lines of code". The second example is just a list comprehension form of my original example, which IMO is less readable for much the same reasons. If you're not super familiar, you'll need to go back and look up list comprehensions. There is no spacing to make it obvious that something particular is being iterated or branched. I understand that ultimately, ease of reading comes down to what style one is most familiar with, which makes it subjective, as you said. But I think there is a stronger rational basis for always preferring the simplest construct that adequately performs the function, which is that in the general case, there is less need to refer back to docs, less possibility of unexpected behavior, and less possibility of strange performance issues.
  - 11y ago
kylebgorman 11y ago
In Python, I'd use use a generator comprehension and str.title(). Assuming I haven't screwed up, then it's just: new_string = "".join(word.title() for word in long_string.split(" "))
- brbsix 11y ago
  Agreed. My first thought was to use `new_string = long_string.title().replace(' ', '')` or the generator you mentioned.

neilparikh 11y ago

Something like the following: capitalize = lambda word: "{}{}".format(word[0].upper(), word[1:]) new_string = ' '.join(map(capitalize, long_string.split(' '))) or: new_string = ' '.join(["{}{}".format(word[0].upper(), word[1:]) for word in long_string.split(' ')]) is much clearer and simpler to me, because it explains the intention of the code: split the string into words, map each word to it's capitalized version, then join it again. With the loop, I have to mentally "run" the code to realize that the for loop and append are to go through the split version and add the converted words to a new list. Obviously, this is a pretty subjective topic, and which version you prefer will depend what you're familiar with/the languages you use.

cookiecaper 11y ago
For me, readability is about how intuitive something is, how much can be understood with basic knowledge of programming in general and perhaps a quick primer on the specific language. I think this is the best measurement because it emphasizes a reliance on the most commonly used, general concepts, and encourages people to use those unless there's a good reason not to. A side benefit is that the more basic language primitives and flow controls tend to be more performant, better tested, and have fewer weird edge cases where they behave in an unexpected manner. I dislike your first example because a) imo, the lack of spacing makes it harder to see what's going on. it's more obvious that something is being iterated in a for loop with a new indentation level than in the map function. b) it depends on the Python-specific implementation of lambda. The behavior of a lambda varies substantially from language to language and lambdas are used rarely enough that it's pretty likely someone who doesn't spend all day every day in Python is going to have to go back and look up the specific behavior. The syntax is much less clear than a full function definition. In my opinion, it's much easier to read code like: def capitalize(str): return "{}{}".format(str[0].upper(), str[1:]) for word in long_string.split(' '): captizalize(word) ... This makes it much more obvious what's going on, and it should be readable to anyone with a passing knowledge of Python, and possibly anyone with a knowledge of programming languages in general. Invocation of map and lambda in this case only make the intent of the program more obscure. I'm not saying that map or lambda are never appropriate to use; sometimes they are. But I don't think it's wise to use them when more basic, universal language constructs do an equally adequate job, especially if the only benefit is "fewer lines of code". The second example is just a list comprehension form of my original example, which IMO is less readable for much the same reasons. If you're not super familiar, you'll need to go back and look up list comprehensions. There is no spacing to make it obvious that something particular is being iterated or branched. I understand that ultimately, ease of reading comes down to what style one is most familiar with, which makes it subjective, as you said. But I think there is a stronger rational basis for always preferring the simplest construct that adequately performs the function, which is that in the general case, there is less need to refer back to docs, less possibility of unexpected behavior, and less possibility of strange performance issues.
- 11y ago

kylebgorman 11y ago

In Python, I'd use use a generator comprehension and str.title(). Assuming I haven't screwed up, then it's just: new_string = "".join(word.title() for word in long_string.split(" "))

brbsix 11y ago
Agreed. My first thought was to use `new_string = long_string.title().replace(' ', '')` or the generator you mentioned.