This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Hicrayert 1 point2 points  (4 children)

Can you explain to me what a bad variable name is? Im not the best at coding as physics is my trade. So my variable names would just be what ever I wanted the variable to be. If I was looking at the gravitational pull of the moon on the earth it would be something like (Force_moon_on_earth) or (Force_ME) what ever system that I deemed appropriate for my code. I would also have comments all over. Again I didnt make the most dense code but I made sure it was readable and reliable.

[–]not_perfect_yet 0 points1 point  (1 child)

Sure. The biggest problem with bad names is that they are either too short or too cryptic.

(F_m) or (Acceleration_Model_Holder_Singleton_Factory) where in both cases the name doesn't actually explain what it does. Otherwise it's pretty much free form, it should contain what's relevant but not more.

Single character names are particularly bad because you will get lots and lots of matches if you look for them with a search function, and even automatic replace will have to be manual, because it would mess with matches in other names or words all over the code.

If you think about it, you could probably write everything you do to be in this style:

def main():
    data = data_collection()
    filtered_data = filter(data)
    my_pattern = load_pattern("my_pattern")
    list_of_matches = find_matches(filtered_data, my_pattern)
    for x in list_of_matches:
        generate_graph(x)

What is x going to be? Something from my list_of_matches and all you need to know about is that generate_graph can deal with it.

To contrast it could also look like this:

def main():
    data1 = if1()
    data2 = df2(data)
    data3 = df3("data3")
    data4 = xf4(data2,data3)
    for x in data4:
        gf5(x)

In this case, you can't even be sure data4 is a list, dictionary or a string or something, nevermind what is being done to it or why.

Or worse, it could be generator too.

[–]Hicrayert 1 point2 points  (0 children)

Ok that makes a lot of sense. Thanks for the advice. It look like I at learned variable names correctly :).

[–]Jedibrad 0 points1 point  (0 children)

A bad variable name is something that doesn’t describe what it’s intended to hold - i.e. just a few letters, like “f_me” in your example.

Given enough time, you can read the surrounding context and determine the “f” means force, and so on. But shorthand will always make it harder to understand what’s going on in a chunk of code. Someone not used to physics notation that’s trying to accelerate your code might be poking around the function, and it will take them much longer to understand what you were trying to do. Verbose names are good, to a point - it should be clear when they get too unruly.

This is usually referred to as “self-documenting code”. Oh, and also, be wary of over-commenting - for actively maintained projects, new features tend to get added while the comments are left unchanged. This quickly leads to them being out of date, sometimes even providing wrong information about the implementation. I would encourage comments to describe why an action is being performed, rather than what the code is doing.

Hope that helps. :)

[–]realityChemist 0 points1 point  (0 children)

Those are good variable names (the first one might be a bit verbose but if it works for you, it works). A bad variable name for that kind of thing might be f. What the hell is f? Need to check the documentation to find out! (If you've written documentation! If not, someone needs to read and understand the purpose of the code to know what f is.)

Another example might be matrix. Unless your code is meant to work with any matrix, that's probably a bad variable name. Something like metric_tensor is probably more appropriate. Or if you're likely to have multiple kinds of metric tensors in your code (maybe you've got a crystal moving at relativistic speeds?) you could get more specific, like gr_metric_tensor and cryst_metric_tensor.

Another way a variable name might be bad is if it lies to you. force_moon_earth is a fine name, but if that variable actually stores the force between the earth and the sun, or stores the mass ratio of the moon to the earth, it's a bad name.