macOS Arithmetic operators on textFileds

[larswik]

Is it better to use arithmetic operators in 'int' format, for example

int x,y,z; 
x = y + z;

;

OR this example which I have gotten use to.

int x;
x = ([textFieldOne intValue] + [textFieldTwo intValue]);

It almost feels like I should convert them to ints before arithmetic operation

int x,y,z;
y = [textFieldOne intValue]; 
z = [textFieldTwo intValue];
x = y + z;

Is their a difference, or proper way?

 

[itickings]

It almost feels like I should convert them to ints before arithmetic operation

If you think about it, where does the actual conversion occur? Is it when you store a value in an int, or when you request the int via intValue?

Anyways, when you can write code in different ways the alternatives are seldom black and white. Pick a variant you are comfortable with, you are sure should work and that can be verified conveniently during for example debugging.

 

[larswik]

Ok, so there is no right way, just different ways in this case. Just trying to develop that good coding practice in my early stages. I was unsure if converting a string to an int on the fly was the best approach.

Thanks...

 

[jiminaus]

An advantage of the 3rd code is that you will be able to see the int returned from each of the intValue messages in the debugger. This can be useful when x doesn't have the value you expect it to have.

Personally I break my expressions down. So I'd break the 2nd code down into the 3rd code. I do this not only because of debug-ability but also because of read-ability. Someone reading my code can take in each part of a complex expression a piece at a time.

There's no performance disadvantage because any compiler will even only basic data analysis will optimise the 3rd code back into the 2nd code.

 

[larswik]

I was about to have a question but you answered it at the end with performance slowdown, not that this is an issue with this small code.

So, over all it is better to elaborate and break down the code to make it easier to read, and for debugging.

That works for me.

Thanks!

 

[PatrickCocoa]

Style

Everyone has their own style. The most important style point you want to implement is consistency: if you do a certain item one way in one part of your code, do it the same way in all parts of your code.

The next most important point is up to you. I've selected clarity as my style choice, and am willing to sacrifice conciseness. So I'd do something different from any of your three examples:

int childsIQ;
childsIQ = ([fathersIQ intValue] + [mothersIQ intValue]);

To me that clarifies what each variable (or text field) contains, and clarifies that the inputs to the equation come from text fields.

 

[larswik]

Yes, that is how I define all my textFields as well. [characterHitPointsTextField] this type of titling is what I have been developing for everything. As a general example I wrote [textFieldOne] just to show what it was and that there were two different textFields. I have gotten in the habbit of correctly identifying my vars, buttons and fields.

Thanks

 

[itickings]

I was about to have a question but you answered it at the end with performance slowdown, not that this is an issue with this small code.

So, over all it is better to elaborate and break down the code to make it easier to read, and for debugging.

Some slightly unasked-for advice (heavily biased towards my personal views), no offense intended:

I can relate to the desire to make things efficient, I really do, but it is IMHO far too early for you to worry about optimization unless you have an actual problem with the performance. (If you do have a problem, it will most likely be associated with loops...)

You are making progress, just continue practicing and focus on writing code that is easy to read and verify. Stop once in a while and think about the statements, what does a statement really do? What is it that happens when you write [characterHitPointsTextField intValue]? Try the debugger now and then even when you don't have a problem.

I know, it doesn't sound like much fun, but once you really get the hang of the basics (such as how classes, objects, variables, methods and so on fit together), most of the fun stuff will come naturally.

I have gotten in the habbit of correctly identifying my vars, buttons and fields.

Great!

Don't hesitate to post code containing such names when you post examples. It can often help other people understand what you intended with a piece of code.

The most important style point you want to implement is consistency: if you do a certain item one way in one part of your code, do it the same way in all parts of your code.

Amen.

 

[Sander]

int childsIQ;
childsIQ = ([fathersIQ intValue] + [mothersIQ intValue]);

I'd like to be that child.

More to the point; I see that it is de rigeur amongst Objective-C programmers to declare a variable in one line and assign it in the next. I wonder why that is; why don't you simply do

SomeType variable = SomeExpression();

Perhaps it's because I'm a C++ programmer, where default-constructing a variable and overwriting it in the next line seems wasteful. Also, it just reads strange to me - it's like the difference between "There's this guy, and the aforementioned guy's name is Fred,..." and "There's this guy Fred,..."

I know these may be unimportant details, but the OP is a beginning programmer and we're talking about style. I agree with all the people repeating Knuth's advice about "premature optimization" but you should also stick to idiom and not be wasteful. For example, whenever you write C++ code like this:

int count_the_spaces(std::string s)
{
    ...
}

any experienced programmer will cringe, and change it into

int count_the_spaces(const std::string& s)
{
    ...
}

You could say that you should only do this if careful profiling has shown that this particular superfluous string copy is a performance issue, but this is simple idiom amongst C++ programmers. On the other hand, if I see in some piece of code that someone has put in hand-coded assembly, I expect to see a comment explaining why he did so, what the timings of the plain implementation were, and on what machine it needed to be faster.

 

[PatrickCocoa]

Consistency

More to the point; I see that it is de rigeur amongst Objective-C programmers to declare a variable in one line and assign it in the next. I wonder why that is; why don't you simply do

SomeType variable = SomeExpression();

Perhaps it's because I'm a C++ programmer, where default-constructing a variable and overwriting it in the next line seems wasteful. Also, it just reads strange to me - it's like the difference between "There's this guy, and the aforementioned guy's name is Fred,..." and "There's this guy Fred,..."

I don't think separating the declare and assign is that big of an issue, although I am willing to talk about it for quite some time. I like to separate the two since they are separate operations. But if you don't want to hold the concept of Fred in your mind while you go to the next line, by all means do both on one line.

I don't know why Objective-C programmers tend to separate the declare and assign, maybe Bertrand Serlat had a twitch when he wrote the first declare and accidentally put the assign on the next line. The next guy saw that and used the same style.

My original point about consistency is more important than the one line vs. two line issue. If you like to do declare/assign on two lines, then always do on two lines. If you like the one line approach, always use one line.

 

[itickings]

I'd like to be that child.

Statistically I'd agree, of course. But I would add a runtime check on the fields fathersIQ and mothersIQ before making that claim, just in case.