Hacker News new | past | comments | ask | show | jobs | submit login

Interesting, my first guess would have been '60' since the old C89 / K&R C had the behavior

   (prefix ops) => ( statement ) =>(postfix ops) 
Which made code like

   *a++ = *b--; 
Change the pointers after the copy as opposed to having them change before the copy.

It is interesting that this has become compiler defined.




It hasn't. You're not modifying a single variable twice within a single sequence point in that example.


That's really all there is to it, isn't it? I've never understood why some people feel the urge to modify the same variable multiple times in the same statement. It doesn't help readability, it's harder to reason about and worst of all leads you directly into the land of undefined behavior, where everything that can go wrong, will go wrong.


Yeah, the need to shove as much code as possible into one line seems to go away with experience. Once you have to debug and maintain that crap you realize very quickly that one liners are not necessarily something to strive for.


I used to strive for clever solutions. The shorter the better. I still like to look at them but I want them as far away as possible from my code base. Sure, if a solution is clever and efficient, while still readable, maintainable and easy to understand when documented properly, I'd use it. However, my general rule of thumb these days is: "Write this code, so an utter idiot can read it". Because that's what's going to happen: One day I'll have to read it again, and I'll feel like an idiot, trying to understand what once went through my brain.

That's something that took me way too long to learn and I feel that novice programmers should embrace that more. We all like to feel like Einstein sometimes, but a big code base is not the place for solutions only we can understand... temporarily.


Also, it's not implementation ("compiler") defined, it's undefined behavior.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: