/prog/ - Programming

Top of the scope, this gives the reader a good sketch of what the procedure is going to do. The exception are loop counter I guess, though I'd argue that having to explicitly declare loop variables like other variables rather than having something like for i in 1 .. n is a language fuckup.

>>5324

The compiler will probably generate the same program anyway so in regards to that it doesn't matter. It's all about how you perceive the code as a reader. And personally, finding 17 variables named along the lines of "a, b, d, gx, gy, xerfsomg, wtf, ffs" at the top makes it just harder to understand what the fuck is going on. To me it's much more readable when you introduce variables when they become relevant, you'll have to read through the function anyway to understand it so I don't get what >>5325 is saying.

>>5326

If you have sixteen variables with useless names in a single function, you fucked up somewhere else. Either make the names useful or split the function up into several functions that do one well-defined thing each.

>>5325

>>5326

I understand both of your points and prefer them being introduced when relevant. But the conflicting opinions really rustle my jimjams because I'm trying to develop the "right" habits for this shit.

>>5328

There is no "right" habit except this: write code that is readable by everyone that has to maintain it. That includes you in three years when you come back to your old-ass code that you don't remember shit about.

You'll learn as you work in programming that dogmatic responses to these questions are all bullshit. It's almost always about the situation at hand. People push the "top of the scope" shit because old C standards required it. Nowadays, put them wherever makes them easiest to manage and keep track of. I declare them all at the top if there are a lot of variables that can be constructed early (or when it makes sense to reuse them) and all are closely coupled. I declare them closest to where they're needed otherwise.

You'll hear tons of programming dogma ("always program in this way", "never do this", "never use gotos", "never use singletons"). Most of it is right for most situations, and none of it is right for all situations. A good programmer follows the best practices. A great programmer knows when it makes sense to deviate.

>>5324

Depends on the language, nigger.

>>5327

honestly this. Many linters will give you a warning that you have too many local variables, and it's true. Local variables are helpers, and they should be set directly before they are being used. If you have a bunch of local variables, either use class/static parameters directly or split up the function. You probably don't need all 16 variables for the same thing, and if you do, put them in an array or something.

>>5343

this so much this. CS niggers in college will try to follow rules and make their code "super-readable". Newsflash: no code is readable. You just have to make is the most understandable, and even that will take a lot of rewrites before you find that yes, this way is the most optimal way of solving the problem at hand. So just do what seems right, get the functionality, and then review and see if you can make sense of the code.

>So redpill me on the variable question. Logically declaring it right before needing it seems like the best thing to do.

Yes, this is best. It's not 1981 any more so we don't need to carry on antiquated practices that were required for the limited memory of the day.

>>5324

Just declare them so that the program can be maximally readable to all the people that are working on the code. If it's just you, then do what's most convenient to you.

It doesn't always make sense to put everything on top.

If say I need a temp variable that I'm only gonna use in a "for" then I'll create that variable on top of that "for" that way everyone knows that that variable is only really used there.