Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing good names

marcelo-cure.blogspot.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Choosing good names

#21

Post by rickr »

guiambros wrote: post #18

The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much. Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, i…

Why do you think it's too much? I think it could probably be named a bit better but what's the downside to having a ~25 char method name?

Re: Choosing good names

#22

Post by crimsonalucard »

rhaps0dy wrote: post #3

I guess the verbosity of the method's name is actually good in this case? Since it makes the function so much clearer. I am never sure how much to abbreviate a name, but I guess if it's not going to be used much it can be long without problems.

Never abbreviate is my rule of thumb.

Re: Choosing good names

#23

Post by vosper »

guiambros wrote: post #18

The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much. Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, i…

The two examples given in support of short local variables names rely heavily on convention or prior knowledge. I don't think they're strong arguments for making short variable names.

Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing "i" they would look strange to most people.

Likewise, tmp draws on existing knowledge of /tmp as the location for temporary data on Unix machines.

Re: Choosing good names

#24

Post by cremno »

thameera wrote: post #13
mtviewdave wrote: post #11

I would have called the function "calculateTransferTax". It's shorter while providing the same meaning. Also, the "tax" argument is the tax _rate_. "tax" in this instance I would expect to mean the final amount. So I'd call that parameter "taxRate". (And I'd use ints for everything, of course)

How would you use ints when there's division in the code? I've heard it's usually better to prefer ints to floating points, but in my limited experience I've found that it's easier said than done.

Use BigDecimal or whatever that kind of type is called in the used programming language.

http://floating-point-gui.de/basic/

http://0.30000000000000004.com/

Re: Choosing good names

#25

Post by Systemic33 »

vosper wrote: post #23
guiambros wrote: post #18

The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much. Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, i…

The two examples given in support of short local variables names rely heavily on convention or prior knowledge. I don't think they're strong arguments for making short variable names. Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing…

The use of i,j,k, etc is a convention carried over from math to CS.

Edit: As are a vast majority of CS knowledge: set theory, calculus, matrix, and so on.

Re: Choosing good names

#26

Post by guiambros »

rickr wrote: post #21
guiambros wrote: post #18

The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much. Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, i…

Why do you think it's too much? I think it could probably be named a bit better but what's the downside to having a ~25 char method name?

Longer names don't automatically make it easier to read. Quite the opposite.

In this particular example, probably the function should be eliminated completely. It's easier to read (value x tax / 100) than to hunt for the spec of calculateTaxOverTransfer() to see what it does. (I'm ignoring the weirdness of representing tax in % instead of a float; that's probably another opportunity for a refactor).

Even if there is reasonable business justification to have a specific function to calculate taxes over transfer (maybe multiple callers, the logic is more complex than shown, or there's expectation that the rule might change) something named calc_tax() doesn't reduce the least of your ability to understand what it does.

If there's business ambiguity (like many types of taxes), then yes, you may need to differentiate which tax you're calculating. Even then, I still prefer the C convention and having a single function that receives a parameter indicating the tax to calculate, like calc_tax( tax_type, amount, rate ).

But one could argue that it's a different use case altogether, and you're better off by refactoring your code, and encapsulating the logic in a class that understands different objects passed as parameters for a calc_tax method.

Re: Choosing good names

#27

Post by confiscate »

thanks for the post.

yes taking an extra 10 seconds to name a function in a more clear way could probably save hours of frantic reading and cross referencing for another engineer down the road, especially when fixing urgent bugs/issues

Re: Choosing good names

#28

Post by baddox »

vosper wrote: post #23
guiambros wrote: post #18

The me the best convention is Linux kernel coding style. I prefer slightly more verbose variable and function names on interpreted languages, to compensate the lack of static type checking, but calculateTaxOverTransfer() is probably too much. Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, i…

The two examples given in support of short local variables names rely heavily on convention or prior knowledge. I don't think they're strong arguments for making short variable names. Naming the integer counter "i" is convention learned in CS class (initially) that has become common usage. If you have nested for loops then j, k are often conventional for naming the next counter variables, though without an enclosing…

Relying on convention is a good thing, as long as your team (and the larger community for that language) is mature enough to have a strong set of relatively easily discoverable conventions.

Re: Choosing good names

#30

Post by jfaucett »

I agree with this post in the general sense, still I think you can go way overboard with this.

If you take as your goal this: "understanding what this piece of code does 1 year from now", as opposed to "I should name these variables and this function fully and correctly" then I think you'll do a lot better each time. There are numerous places where I can more quickly and easily consume "i" as apposed to "someArrayIndex", or "fname,lname" instead of "firstname, lastname", etc.

Post reply on HN