Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
1. Someone else won't necessarily know that this was intended unless you have a comment telling them. That comment would take up just as much space as putting an 'a = b;' line before the 'if (a)' line.
2. If your compiler is not capable of optimizing and figuring out that 'if (a=b)' and 'a=b; if (a)' should generate the same machine code, then your compiler is a piece of crap and should be upgraded or replaced.
3. If you get in the habit of doing those kind of 'shortcuts', you are more likely to accidentally do the wrong thing. And since you're so used to that kind of programming, you're more likely to miss it when trying to track down the bug that you introduced. If 'if (a = b)' just looks wrong to you because you never use it, it is more likely to jump out at you when you're debugging, whether it's your own code or someone else's.
The same thing is true for casting ints to pointers, having fall-throughs in switch statements, signed/unsigned mismatches, and a myriad of other "legal" but "just-as-wrong" things.
Elephants in the wild can understand human pointing. http://www.decodedscience.com/elephants-understand-pointing-better-chimps/38097
So, sure, chimps may not natively understand human pointing, but dogs only got that way because of thousands of years of selection of offspring that cohabit better with humans. Take a wolf and point, it won't understand.
Over the past few months, my org has moved from waterfall to scrum, and while the transition is painful for some people, I think it's really simple to grasp. We no longer have the 3-day meetings of adds/cuts to figure out what features we think we'll be able to ship in the next 2 years, we just have an idea of the bigger items we want to accomplish. Things that we need to do sooner rather than later are more detailed, such that we know whatever work we think we'll be doing over the next 2 sprints is very clear and detailed, with increasing fuzziness the further out we go.
We only work a sprint at a time (2 week schedule), make sure everything is as tested as we can before calling it complete. If we find gaps in our coverage before the sprint is complete, we fix them then and there (no checking in things with "known issues"). If we find gaps after the sprint was completed, we add them into our backlog for handling in the future, so we don't context switch out of our current work to service code. It's actually quite a blessing.
We're not a well-oiled machine yet (will take a while), but I think people are getting it more and more.
I don't think agile is necessarily the right tool for everyone or everything (I know some agile purists would disagree), but for the way we were doing waterfall before and all of the problems we felt year after year, I feel agile development is exactly what our org needed.
Grammar is about the syntax and structure, not about the definition of the word.
I assume that you think that "syntax" means "definitions of the words", based on your reply, but if you look at the definition of the word syntax, you will see otherwise. Syntax is about the arrangement and interactions of words, not about the meanings of them.