The int declaration is redundant because you turn around and use it once, then it falls out of scope so you can't use it ever again. "int some_descriptive_name = 1; somehow_use(some_descriptive_name);" would be valid and I do things like that, but not with "a". (Barring some exceptional context where "a" really is descriptive; for example, encryption algorithms following the spec closely, which is just about the only exception I'll grant to "never use lots of single-char variable names".)
Yes, if (b = 0) { is syntactically correct but the odds of you meaning it are effectively zero.
The function declaration was legal, for the purpose of highlighting the call where the & is used incorrectly. Making that illegal would significantly complexify the task of saying where the error is. Of course it's such a steaming pile that it's arguable no matter how you slice it, that's what happens when your code is semantic nonsense.
BTW, I'm just clarifying, we're pretty much in agreement, just with different emphases.
(Also, I like the cout line, now that I look at it the next day. I'm tempted to slip that in to a test somewhere. It wouldn't be a "no hire" if it was missed in an interview situation, but it would be an interesting way of seeing how detail-minded the interviewee is.)
Comments
The int declaration is redundant because you turn around and use it once, then it falls out of scope so you can't use it ever again. "int some_descriptive_name = 1; somehow_use(some_descriptive_name);" would be valid and I do things like that, but not with "a". (Barring some exceptional context where "a" really is descriptive; for example, encryption algorithms following the spec closely, which is just about the only exception I'll grant to "never use lots of single-char variable names".)
Yes, if (b = 0) { is syntactically correct but the odds of you meaning it are effectively zero.
The function declaration was legal, for the purpose of highlighting the call where the & is used incorrectly. Making that illegal would significantly complexify the task of saying where the error is. Of course it's such a steaming pile that it's arguable no matter how you slice it, that's what happens when your code is semantic nonsense.
BTW, I'm just clarifying, we're pretty much in agreement, just with different emphases.
(Also, I like the cout line, now that I look at it the next day. I'm tempted to slip that in to a test somewhere. It wouldn't be a "no hire" if it was missed in an interview situation, but it would be an interesting way of seeing how detail-minded the interviewee is.)