Printable View
Is it considered bad practice to do this?
In other words, is it bad practice to use a pointer twice as I've done above? If so, what's the correct thing to do?Code:#include <stdio.h>
#include <stdlib.h>
int main(void)
{
unsigned char* fileContents;
//Following function returns a memory location of heap-allocated data
fileContents = GetFileContents("foo.txt");
free(fileContents);
fileContents = GetFileContents("bar.txt");
free(fileContents);
return 0;
}
I don't believe it is [bad practice].
lol linked lists and trees and stuff reuse pointers for head and tail constantly, so infact it's common practice
you just gotta make sure you dont shoot yourself in the foot doing it :goggle:
I believe it's only bad practice if the pointer name is ambiguous and is used in significantly longer sets of code. Since yours is contextually relevant to what it does, and there's only two lines, it's simple to understand and no confusion should occur about it being reused for a different purpose or the value being changed in such a way that would be difficult to follow by hand.
Correct practice would be to have anything named to be contextually relevant, and simple to read and understand from a third person perspective.
This. It's ok because the variable name is accurate and descriptive in both uses and the uses are very close together. If the uses of the variable were different and you were just trying to save 4 bytes, that would be bad. Code readability > 4 bytes (and the compiler might optimize it so both variables use the same memory location anyway).Quote:
Originally Posted by JoeTang
By the way, if there's no reason you need to use C instead of C++, you should use std::vector and std::string instead of raw dynamic arrays whenever possible. Manual memory management is error-prone.
Resuing a variable is bad because novice programmers forget to release the memory which causes leaks etc. You can reuse a variable as long as it makes sense, and it isnt being used/have already been released.
There's one rule I always followed, especially when it comes to parsing/fetching database data. That is after you finished processing it, free it right after. An example of that is:
$res = mysql_query('SELECT blah from some_db.some_table');
while($row = mysql_fetch_object($res))
{
// do something
}
mysql_free_result($res);
As you can see, $row get reused multiple times. Its fine, because it holds instances of the same entity.
As for the comment about pointers in linked list and tree, that's another dimension reusing variables. While, technically, you only remapping head/tail rather than freeing > assigning values to it (as per your example), it shows that it is a sensible situation to resuse those variables.
When in doubt, create a new variable.
Is it bad to assume that the ones continuing/reusing the code are smart programmers? Or, even more, that they have to be?Quote:
Originally Posted by GummyBear
I mean, is it bad to program in a way which means its reader has to be smart to understand what's going on?
Yes. The worst.Quote:
Originally Posted by Devil's Sunrise
I've often heard, "If you need comments to explain what the code is doing, recode it." The coding should be self-evident so that other people can follow your source code and train of thought. If commenting might help a third party (such as commenting large blocks of code with "//Initializes administrator commands"), then do it.
You are taking things out of context. I was purely speaking about Fiel's case. There's a big gap in reusing code vs reusing variables. Generally, the problem is not the principle of reusing a variable, but rather the human errors associated with it that prevents them from being mainstream.Quote:
Originally Posted by Devil's Sunrise
Because of that, OOP were taken upon, and one of the main emphasis of OOP is variable scoping. You dont need to be a smart programmer to reuse variable. We human do make mistakes and thus it's not advised. If you are careful enough to, then by all means. That's what I referred to as common sense.
Dont tell me in your programming career, there's never an instance where a variable does not have the expected value. Even after 7/8 years programming, I still make that mistake sometimes.
Short answer, yes.Quote:
Originally Posted by Devil's Sunrise
Long answer, usually, if you're doing something beyond the norm, it's best that you explain it in a comment. Not only that it helps the next programmer, it helps you when 6 months later, you have to modify/enhance it.
Back in uni, I used to think I can understand anything and thus do not need comments. Then there were days when I bit my pride. Now, my principle is if a random programmer cannot understand what I am doing, it needs to be explained further. If you're stingy on time writing a comment, you'll waste 10x as much trying to re-understand your own code later.
This is an example:
$current_time = (time() >> 10) << 10;
Firstly, its in PHP. A language that can spoil many laziness. Secondly, it uses bit-shifting. A technique we don't often see in higher level languages and/or isn't streamline.
Without adding the comment:
// rounding down to the nearest 1024 seconds block (every 17.1 minutes)
It's pretty cryptic for the next programmer to read. They'll be like wtp did the old dude doing here?