25% (10)
74% (29)Just interested in what you guys think about this because I'm always seeing it as a problem in newbie code but some people don't think it's a problem.
So, lets gather proof that it is or it isn't.
ID:1240701
 Apr 18 2013, 6:12 pm
|
|
Why isn't there an "It's not a real problem" option? It's just you being nitpicky, as long as the programmer is being consistent in his own style.
| |
I could swear that ++ compiled down to += 1 anyway.
Also, I've never understood the confusion of the side-effects of ++i/i++. Seemed incredibly obvious to me. Also, your poll won't result in proof. Appeal to consensus is a logical fallacy. | |
I agree with Kaiochao, it's all about your style... And what LA said, there isn't really a better way. Just like, you could make an attack system many ways and have all of them doing the same thing.
| |
If there's a "who cares, really?" option, I'll go for that one please. If you are getting anal on += versus ++, lord knows how you complete an entire game.
| |
Actually when you have good style it makes development a lot faster. Thought you'd of known that Stephen.
| |
Not quite, no, the inverse holds true though. The thing here is, neither (or even doing a little switching between) are bad style. As a for-instance, the project I'm on at work at the moment has 25 developers and a code review process, and if I left someone a code review comment to change a += 1 into a ++, they'd rightly ignore it as being anal, because they have better things to be doing with their time.
| |
I thought using += and -= were better because
i = i + 1 would allocate a temporary variable to do the maths. | |
I think the important question is, for most cases, who cares, really?
Memory-wise, that's entirely internal and probably vanishes immediately when the operation completes, or at worst when the stack-frame goes. CPU time wise, that's all trivial, unless you're doing so in a seriously tight loop. I put serious doubt behind the idea that someone's taken a game that is lagging, and made it perform much better by replacement of += or = i + 1 with ++ alone. That is not the critical path operation for most games here. | |
This is the kind of debate I'd want to punch somebody for in a professional setting. The fact is that it completely does not matter, especially in the context of operations we're doing on BYOND.
Stephen001 and Ter13 are completely correct, and I'd slap one of my developers if they started arguing with the team about stylistic decisions this small. client.control_freak = TRUE | |
Kinda has a point too lol. Which would you prefer..
usr.Attacking = 1 or usr.Attacking = TRUE That's just like += / ++ | |
I only use usr when it's inside of a verb (just started doing this like last week), a client, or something of that type. I stick with src.
| |
Galactic Soldier wrote:
This deferring of usr propaganda again... Ignorance certainly is not bliss. There is no propaganda. There are clear instances where usr should be used - most of the time nothing specifically needs to be dereferenced. The majority of the time, outside of functions where usr has to be used to interact with the client like Click(), src is what you want and it doesn't even need to be explicitly there. | |
Also, ++i would be faster than i++ because one doesn't create a copy (not that it really matters, the speed is probably not going to be noticeable lol). If that's how it works in Byonds code
| |
Kyle2120 wrote:
Also, ++i would be faster than i++ because one doesn't create a copy (not that it really matters, the speed is probably not going to be noticeable lol). If that's how it works in Byonds code Normally you would be correct. However, in having done pretty extensive research on the DMB format I can say that this is not the case. LordAndrew wrote: * While not "better", one also has to consider that i++ and ++i have different side effects. When used as part of an expression, this is true; however, it does not hold any weight as a standalone statement. While x = ++i and x = i++ are very different, a standalone ++i; actually compiles to the exact same bytecode as i++;. Ter13 wrote: I could swear that ++ compiled down to += 1 anyway. Not quite. To expand on what I was just saying, in the imaginary assembly language of BYOND: proc/foo(i) BYOND's compiler really doesn't optimize much of anything, so the actual line i += 1 should use another set of instructions and more bytecode. ----------------------- Strictly speaking, I would argue that using the ++/-- operators to increment/decrement is better. Why? Shorter bytecode. But unless it's used in a really freakin' intense algorithm or in a ridiculous loop, who cares? You'll never notice. Add 1 in the way your eyes find it prettiest (I prefer ++i, personally), and move on. If you're looking at this for a performance boost, then look elsewhere. | |
Galactic Soldier wrote:
Just because that's the optimized way to do in assembly, doesn't mean BYOND does that You missed the part where I said I've "done pretty extensive research on the DMB format." I have reverse-engineered the DMB format and gained a very thorough understanding of the translation the DM compiler makes from your code to the DMB bytecode. I'm telling you that this is in fact the way that BYOND does this, and that there is indeed an observable difference in performance of many thousands of iterations. The only thing is, this is such a negligible difference as to only be realized over so many iterations that if this is the optimization you're trying to make, you need to re-analyze your code for other problems. --------------------- Since I'm sure you haven't reverse-engineered the DMB format yourself and there's no reason you should take my word for it, here's a simple proof of my point. #define DEBUG 1. Create that in its own environment 2. Run it 3. Press F1 -> Server -> Profile... 4. Use the verb one time. Wait just about a second or two to be sure it's done. 5. Open the profile window and hit refresh. Something like this?  (If you have a slightly decent machine, you may need to up the iteration count. I've had my laptop since 2008 and it has quite a failing hard drive, so your performance results may vary.) You'll notice a distinct difference between the call time of a()/b() and c(). But it's such a small difference over 500,000 iterations that it's not even worth fussing over. ----------- I really don't think you know what you're talking about. You're relatively new (2010?); I'll cut you a little slack. I've been programming with BYOND since 2002, so I do in fact know what I'm talking about. | |
* While not "better", one also has to consider that i++ and ++i have different side effects. In JavaScript (if you adhere to Crockford's code conventions, anyways) the suggested method for iterating an integer is to use the form i += 1 to avoid the "trickiness" of the ++ operator and its pre- and post-fix side effects.