3 ms·
On Collecting Results in Temporary Variables - His 'more idiomatic' code is both harder to read (arguably) and harder to debug. In his "bad" example, it is ver
by pdntspa 2y ago
On Collecting Results in Temporary Variables -
His 'more idiomatic' code is both harder to read (arguably) and harder to debug. In his "bad" example, it is very easy to set a breakpoint at each important step of the function, or insert logging, or whatever. The enumerable approach yields fewer lines but it's really difficult to stop the code and examine where something went wrong. Not to mention it's a bunch of symbol soup gobbledygook that takes a lot more specific Ruby knowledge to decipher.
Personally I'm all for temp vars. When I have to come back to the code in 18 months or whatever I will thank myself for making it so easy on me.
- pmontra 2y agoI'm with you about readability however the supposedly idiomatic way might be faster. I didn't run a benchmark but intuitively the more you stay inside the methods implemented in C inside the interpreter, the faster your code runs.
- zelphirkalt 2y agoAll in good measure. Too many loval temporary variables are quite annoying as well, especially paired with bad naming. When the names are like "thing_with_attr1", "thing_with_updated_attr1" and so on, it also becomes confusing which variable has what, when they are later used. Having variable assignment after assignment after assingment is also an indication for a function potentially doing too many things and might even be called a code smell.