LemonDrop 
"[@NotAPseudonym":](/1941318#comment_7824236
)
Again that is bad practice in C++____ due to the performance problems it can cause with more complex objects. The compiler cannot magically defer initializations if they're complex enough at times since they may have potential side effects, so yeah it's just always good to only initialize things when you absolutely need to, not at the very top. Furthermore it promotes leaving variables in an uninitialized state (which is more bug-prone), or even worse, a default constructed state if it is an actual class rather than a primitive type (overhead which could be avoided assuming the class even has a default constructor to begin with), not to mention force the what should be initialization to be a copy or move assignment (which will destruct the previously default constructed object and waste even more time).
If anything too, the fact that this was an explicit design decision in C____'s creation should be hint enough on what the good way to do it is, since they knew it'd be a problem with how C did it at the time and changed it, which C99 promptly took back from C++98.
Additionally style wise I dislike putting everything at the top since within the context of a potentially hundred line long function you forget what those variables' types are easier and stuff like that, creating an absolutely huge monster mess at very top which isn't useful to anyone either when refactoring code rather than just finding things near where they are used. Sometimes in rare cases too you may end up with conflicting variable names if two things should be named the same for whatever reason, and keeping things more local to scopes would have a higher chance of avoiding such an issue. Finally if you're not using initialization and preferring assignment, you miss out on features such as list-initialization which allows for additional checking and uniform syntax of class and primitive type initialization of all kinds, which I personally use everywhere.
Tl;dr, don't do it. C and C++____ even more strongly are all about scopes, if we didn't care for them then we'd not just only put all our variables at the top of functions but just make everything global and put it in 1 file for easy access. Limiting scope of information makes programming easier for the programmer, more performant and introduces potential optimizations more clearly for the compiler.
"
[@Background Pony #E8A7":](/1941318#comment_7824433
)
That's good, but it just bothers me that they'd choose that style of declaring variables when in C++____ it shouldn't make any difference for debugging purposes either way. I'd argue even the method of deferring initialization in this case would make debugging easier as the variables listed for debugging in a step by step view would only be those who are actually relevant to the current scope depth that is being inspected rather than having them all thrown on you at once.
C++ Crazed
Again that is bad practice in C
Additionally style wise I dislike putting everything at the top since within the context of a potentially hundred line long function you forget what those variables' types are easier and stuff like that, creating an absolutely huge monster mess at very top which isn't useful to anyone either when refactoring code rather than just finding things near where they are used. Sometimes in rare cases too you may end up with conflicting variable names if two things should be named the same for whatever reason, and keeping things more local to scopes would have a higher chance of avoiding such an issue. Finally if you're not using initialization and preferring assignment, you miss out on features such as list-initialization which allows for additional checking and uniform syntax of class and primitive type initialization of all kinds, which I personally use everywhere.
Tl;dr, don't do it. C and C
"
[@Background Pony #E8A7
That's good, but it just bothers me that they'd choose that style of declaring variables when in C