An object is initialized (constructed) the moment it is declared. If you don't have enough information to initialize an object until half way down the fn, you can either initialize it to an "empty" value at the top then "assign" it later, or initialize it correctly half way down the fn. It's cheaper (in runtime performance) to get it right the first time than to build it once, tear it down, and build it again. Simple examples show a factor of 350% speed hit for simple classes like "String". Your mileage may vary; surely the overall system degradation will be less that 300+%, but there will be degradation. Unnecessary degradation.
A common retort to the above is: "We'll provide "set" methods for every datum in our objects, so the cost of construction will be spread out." This is worse than the performance overhead, since now you're introducing a maintenance nightmare. Providing "set" methods for every datum is tantamount to public data: you've exposed your implementation technique to the world. The only thing you've hidden is the physical names of your member objects, but the fact that you're using a List and a String and a float (for example) is open for all to see. Maintenance generally consumes far more resources than run-time CPU.
Locals should be declared near their first use. Sorry that this isn't familiar to C experts, but "new" doesn't necessarily mean "bad."