tag:blogger.com,1999:blog-8288194986820249216.post2616828287328800007..comments2024-03-22T05:09:17.789-07:00Comments on Abstract Heresies: InterludeJoe Marshallhttp://www.blogger.com/profile/03233353484280456977noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8288194986820249216.post-86019481820832547122009-06-05T17:58:02.030-07:002009-06-05T17:58:02.030-07:00I'm with the first 3 commenters: it's typi...I'm with the first 3 commenters: it's typically a leftover construct from development, though if it's a gnarly function call, I do prefer to have it on its own line. There's plenty of room for disagreement, but I don't think there's a hard and fast rule to be applied in languages that aren't tail-recursive.<br /><br />Having matured in the era of servers with many megabytes of RAM, the extra couple bytes of the temp variable just hasn't been a concern. =)Chris Dhttps://www.blogger.com/profile/11377834549568033187noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-51567737854167433622009-05-03T12:50:00.000-07:002009-05-03T12:50:00.000-07:00Chris,
If you think that's bad, you should see so...Chris,<br /><br />If you think that's bad, you should see some of the legacy code that I inherited. It's about 6k lines of C and most of the variables are named i, i1, i2, i3, i4, etc. :-/<br /><br />The worst part is that the poorly named variables are only a minor annoyance compared with everything else that's wrong with the program.Joshhttps://www.blogger.com/profile/17197946799986500561noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-78978734607833802292009-05-01T10:12:00.000-07:002009-05-01T10:12:00.000-07:00In my job I review and debug a lot of other people...In my job I review and debug a lot of other people's C code, and the use of superfluous temporary variables is a <I>huge</I> pet peeve of mine. IMO, superfluous temps, more often than not, serve only to obscure the code.<br /><br />If I need to debug something, <I>then</I> I can insert the necessary temps. But sticking temps everywhere <I>in case</I> I might need to debug something? That sounds insane to me.<br /><br />As a simple example of the obscuring power of superfluous temps, here's a reduced version of something that I recently ran across in production code. It made me crazy:<br /><br /> int tmp, tmp2;<br /><br /> tmp = getValA();<br /> tmp2 = getValB();<br /> printf("A is %d, B is %d\n", tmp, tmp2);<br /> tmp = getValC();<br /> tmp2 = getValD();<br /> printf("C is %d, D is %d\n", tmp, tmp2);<br /> tmp = getValE();<br /> tmp2 = getValF();<br /> printf("E is %d, F is %d\n", tmp, tmp2);<br /> tmp = getValG();<br /> tmp2 = getValH();<br /> printf("G is %d, H is %d\n", tmp, tmp2);<br /><br />This went on for something like 20 separate printfs. (There were no As, Bs, Cs, and so on; the actual values being retrieved were various hardware registers. To make matters worse, this code was part of a crashdump-generating sequence where no one was about to attach a debugger anyway.)<br /><br />I acknowledge the potential documentary power of a well-named variable, but my experience suggests that giving names to things for immediate use (and discard) is most often an exercise in futility.chrishttps://www.blogger.com/profile/15186090883838820294noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-6575816421230370452009-05-01T08:17:00.000-07:002009-05-01T08:17:00.000-07:00Yeah, it reminds me of something that Gerry Sussma...Yeah, it reminds me of something that Gerry Sussman said in favor of obscure higher order functions. He had some code with a couple of random functions like "compose-and-curry-second-arg" or something really random like that, which would have been shorter to write with a lambda. He said he prefers the version with the named function because names are easier to read and debug. I think it was something along the lines of "naming something gives you power over it".<br /><br />However, it's a stretch to apply it to what you're talking about :).Reid Khttps://www.blogger.com/profile/10131127807440335781noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-20081514825546556892009-05-01T07:38:00.000-07:002009-05-01T07:38:00.000-07:00I'm echoing the previous two statements. Giving a...I'm echoing the previous two statements. Giving a name to the value <I>should</I> lodge enough information in the debugging information to let debuggers, tracers, etc. present their data a little more clearly. And sometimes I use such an assignment as documentation. I wouldn't use a name like foo but rather final_bfs_depth (or preferably something more about the purpose). That can add a little documentation about intent while also making the symbol available for tab-completion and other gizmos.<br /><br />So the assignment isn't for communication with the CPU, it's for communication with tools and with people.Jason Riedyhttps://www.blogger.com/profile/17641550258214604241noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-89636342131042718252009-05-01T05:02:00.000-07:002009-05-01T05:02:00.000-07:00I sometimes have this structure in my code as the ...I sometimes have this structure in my code as the aftermath of having inserted a print statement between the variable binding and the return. After the print statement is removed, you have the pattern shown in Joe's post.Paul Stecklerhttps://www.blogger.com/profile/13416750891822431224noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-53340243670456047412009-05-01T03:07:00.000-07:002009-05-01T03:07:00.000-07:00I often do it that way for ease of debugging. That...I often do it that way for ease of debugging. That way I can set a breakpoint at the return statement and look at the value of foo. If done the inline way I have no easy way to step over the function call and watch the value before it is returned. I trust the compiler to be able to optimize it away anyway.Alex Meyerhttps://www.blogger.com/profile/18338952940396521355noreply@blogger.com