41–50 of 175 posts
In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.
take n (filter (> 0) xs)Good advice. If this sort of thing is appealing to you, then read Code Complete by Steve McConnell. It's basically an entire book full of very solid advice of this sort.
Off-topic, but blogspot links are a constant frustration for me on the phone. It's super easy for my fingers to swipe slightly left/right when scrolling and triggering blogspot's next/previous post navigation. I can even accidentally end up slightly scrolled horizontally and have no way to see the left side again. As a result I mostly ignore blogspot links. But this seems up my alley ( http://akkartik.name/post/reada…
Reader view on iOS makes blogspot, and lots of other articles, quite bearable. (I assume it works?)
Edit: Firefox on Android seems to eat much of the article in readable mode, while Chrome or Opera on Android seem to have none. So I'm back at square one..
A good guide, but I didn't like this part: Avoid Over-used Cliches In addition to not being Teutonic, the following variable names have been so horribly abused over the years that they should never be used, ever. val, value result, res, retval tmp, temp count str Cliches? If you are trying to communicate, these names are well known ways to do that. If there is something more specific to put in there, by all means, bu…
"rather than the elliptical vagueness of Romance languages like English" - what?
Earlier quoted context omitted.
A convention I've always done for this is to just use a plural name. There are fewer errors based on mixing up the names than you'd think, and it's very readable. for fruit in fruits: assert fruit is not 'apple' print(fruit) assert 'banana' not in fruits etc. Especially in Python, it makes code flow very much like English. Edit: It also goes with the "don't put the type in the name" point, which I agree with in most…
Even where the convention isn't to use natural language names, something like this is fairly common (e.g., in lots of fairly terse functional language the convention is to use, e.g., "xs" for a list and "x" for a member -- in some with destructuring matching on lists, the convention is "xs" for the list, "x" for the head, and "xr" for the tail (rest) of the list.)
`movie_collection` vs `movie_collections` is a bit trickier
In dynamic languages, like Python, I think it's often good to call variables something like `fruit_list`, to quickly pick up on a bug where ie: `fruit_list == {'apple'}`.
That feels like an ad-hoc reinvention of half a type system. If you want to keep track of your values' types (and you should), why not use a typed language?
I like type systems when I play around with personal projects in well-typed languages
when it's coding as fast as humanly possible, the last thing I want to do is slow down to think of good var names. I'll often just name something "foo" if I can't think of a good name and come back and rename it later. Sometimes it's a little better than foo but still not perfect but I'll leave that and move on to something else. I really don't like the idea that code must be perfect. Code is never perfect.
A good guide, but I didn't like this part: Avoid Over-used Cliches In addition to not being Teutonic, the following variable names have been so horribly abused over the years that they should never be used, ever. val, value result, res, retval tmp, temp count str Cliches? If you are trying to communicate, these names are well known ways to do that. If there is something more specific to put in there, by all means, bu…