But what happens if you die and someone else has to pick up where you left off?
The world will stop turning and it will all have to be rewritten from scratch.
The typical response of a developer inheriting legacy code from a no-longer-employed-there developer is "this is garbage, I need to rewrite it". So in that sense not only is 'foo' efficient for the original commenter, it is _also_ efficient for his/her replacement since it will present a very clear business case for a rewrite.
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?)
I love it when people use generic names and then add a two word comment describing what it is. I also love it when people use primitives for time spans along with the units in the name or comment instead of TimeSpan/std::chrono.
My favorite is when people use a good variable name and then put a two line comment explaining what I could gather from the variable name.
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'}`.
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…
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'}`.
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.)
Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…
I think it works here because you're in a context where there's just one collection. So you don't really have to remember what c means, you can see c.size() and think "this is the size of the collection", because in this context there's only one thing you could be taking the size of.
If there were more than one collection, or we weren't using it in a way that makes it obvious it must be a collection, I would want a better name.
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.
Well, grasshopper, I guess you can code like a kung fu novice, trying to split a stone; repeatedly and thoughtlessly bashing your hands on it, making a bloody mess. Or like a master; contemplating the best way a while and then splitting the stone whith one precise, decisive motion.
Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…
I find that single letter variable names (or 2-letter names for that matter) really only work if both your coding style and your language allow it. You have to write short functions (5-20 LOC or something like that) in a language that encourages that style. C, Go, LISP, and Haskell (and many more) are great for this kind of thing. But object oriented languages like C++ and Java tend to have much longer functions (50-100 LOC isn't uncommon). I'm not sure the fact that they're object oriented has anything to do with that though.
Most of this, even if it's not my preference, I would never bother arguing with. But I have a question about a practice that is tremendously widespread. I have real trouble with single-letter variable names like "c", for any function more than, say, 2-3 lines. I scan the code and it increases my mental load because I have to remind myself what it means. Obviously a lot of people don't have problems with this, but I d…
I agree. It's not a mental tax to read a word we recognize. It's not like we have to sound it out letter by letter, we recognize its form at a glance. It's more taxing to maintain a mapping for an inherently meaningless single character.
Although there are some single characters that do have meaning due to long time convention such as 'i'.