Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
int *itPins = pins;
for(int i = 0; i < count; i++)
{
    ConfigureGpifPinAsGpioOutput(itPins);
    itPins++;
}

I have the impression that doing two things in one line is bad practice. This is why I am advancing the iterator outside of the only statement, using it. However, I feel blindly following a rule.

  • Is this code less error-prone than if the ++ is inside the function invocation?
  • Why?
  • Does this rule apply to such ultra-simple cases or is it meaningful only for more complex program structures?
share|improve this question
2  
A "side effect" is something non-obvious that a routine does besides yield a return value. But that's not what you're talking about, is it? Your point is whether to pass the counter and advance it in one statement or in two separate statements. That's not a side effect, that's just a question of doing more or less in one line of code. –  Kilian Foth Dec 13 '13 at 9:05
    
I dont think this is an example of "side effects" unless void ConfigureGpifPinAsGpioOutput(T*& pins) { pins++; } is the function. –  Charles Beattie Dec 13 '13 at 9:23
1  
@CharlesBeattie: Unless ConfigureGpifPinAsGpioOutput is functionally pure (and therefore pointless), this does show side effects--the question just isn't about that. –  Phoshi Dec 13 '13 at 9:25
1  
Having an unused counter variable and incrementing something else instead does look like something's wrong to me. for (int *itPins = pins; itPins < pins + count; itPins++). –  aragaer Dec 13 '13 at 9:45
1  
This is a textbook example of why some companies develop coding standards. To some people, a line of code is clear and consise whilst to others it is unduly terse and hard to read. –  Robbie Dee Dec 13 '13 at 13:27

4 Answers 4

up vote 26 down vote accepted

It is not always bad practice to do multiple things on one line, but it does have a higher risk of making the program appear more complicated that it needs to be.

If I were pedantic, I could argue that in the line for(int i = 0; i < count; i++), you are also doing multiple things, but very few people would mark that line as a violation of the rule.

On the other hand, if you had a line like ConfigureGpifPinAsGpioOutput(itPins++);, then the increment in the argument does increase the complexity as I would have to look twice to be sure that the code is correct and I would probably flag it as needlessly complicated.


Another way to write the loop is like this:

for(int i = 0; i < count; i++)
{
    ConfigureGpifPinAsGpioOutput(pins[i]);
}

where you rid yourself completely of the issue.

share|improve this answer
3  
To my eye, your revised code makes much more sense. –  Robert Harvey Dec 13 '13 at 19:41

It depends. Most times I would to avoid such things, but in a simple case like this

 ConfigureGpifPinAsGpioOutput(itPins++);

is very idiomatic for most programmers with some experience in the C families of programming languages. With some experience in C code reading, it is IMHO as easy to grasp than the two lines of code in your example.

So I would not be too picky about this special case.

share|improve this answer
2  
Good point about idiomatic code. –  Vorac Dec 13 '13 at 11:31
    
You raise an interesting point here. There is an argument for making the code easier to read for developers coming from another language. The counter-argument is that you end up with a lowest-common-denominator approach that doesn't always make best use of the built-in language features. –  Robbie Dee Dec 13 '13 at 13:41
    
I do not understand why this answer is not getting more upvotes. –  Vorac Dec 13 '13 at 15:46
1  
That makes 2 of us. Talk about casting pearls before swine... –  Robbie Dee Dec 13 '13 at 15:52
    
Does putting the increment statement outside of the function call have any deleterious effects in C? One would never combine statements in this way in C#, as the only benefit would be one less line of code in exchange for less readability. –  Robert Harvey Dec 13 '13 at 19:38

This is a matter of style, and there is no definitive answer. There are some C programmers who are more dogmatic and will hate code with multiple statements per line. Almost no one will object to code where each statement is on a separate line. If there are people on your team who hate seeing multiple statements on a line, then just don't do it. Argue about something more important. If the team is just you, then suit yourself.

In your specific example, the best answer is to eliminate i and directly iterate through the pin numbers:

for(int* p = pins; p < pins + count; ++p) {
    ConfigureGpifPinAsGpioOutput(p);
}

BTW, there are lots of C programmers who will really hate your quasi-Hungarian naming conventions.

share|improve this answer

Is doing two things on one line always a bad practice?

Maybe not always, but more often than not it's a bad practice.

For example, chew on this version of your code instead:

for(i = 0; i < count; pinConf(pins[i++]));
share|improve this answer
    
In this case, you can do "+1 mistake". –  Margus Dec 13 '13 at 10:14
6  
Can you elaborate your answer in how this answers the question. –  Bart van Ingen Schenau Dec 13 '13 at 10:40
3  
[mentally refactors code into readable format] yes, but that seems like an example of how to write something in the least legible way possible –  Richard Tingle Dec 13 '13 at 13:28
    
I did the +1 mistake. :) I hate SO as much as I love it just because in many occasions people don't get the pun or deeper meaning of a post, trying to prove how stupid the post is (or the poster). It so similar to retarded d***-measuring we often see at work... –  LavaScornedOven Dec 13 '13 at 18:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.