• Post Reply Bookmark Topic Watch Topic
  • New Topic

Naming fields  RSS feed

 
Bartholomew Benson
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which is considered clearer and better for naming?



vs.



I've always been really elaborate with my names, because I thought that being more descriptive is more precise and lowers the chance that names might clash with each other, but then I noticed that a lot of my code becomes really lengthy and tiring to read, ie.:


(I don't know if this code even works, but you get the idea)
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I opt for longer, more descriptive names as I find it increases, rather than decreases, the readability and clarity.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bartholomew Benson wrote:I've always been really elaborate with my names, because I thought that being more descriptive is more precise and lowers the chance that names might clash with each other, but then I noticed that a lot of my code becomes really lengthy and tiring to read:

Yeah, it's a tough one.

In general I agree with Bear; but at some point you hit a point of diminishing return. I also think that you need to be very careful (assuming we're talking about field names) to describe what it IS, not what it DOES. Quite a lot of library code I've seen falls into that trap and, even if it doesn't, you sometimes get some horribly verbose names.

To paraphrase Einstein: it should be as descriptive as possible, but no more so. Anything that involves type, for example - like Hungarian notation - is naff AFAIC.

Another thing that can be very useful is context: Map.Entry, for example, is extremely descriptive, without being overly verbose.

And just one trivial thing: I tend to make my array names singular, and my collection names plural, viz:
private Student[] student;
private List<Student> students;

and it's simply to do with the way you use them. I just find:
Student graduate = student[3]; and
Student graduate = students.get(14);
easier to read; but it's a very minor thing. And definitely don't name a Student field 'stud'.

All I can say is: be a good editor. When I was a kid, one of the things we were taught was how to write business letters, and the rule was: short, sharp, and active:
  • Don't use a 25-cent word when a nickel one will do.
  • Avoid the passive tense.
  • Brevity is the soul of wit.

  • And above all, read what you've written.

    HIH

    Winston
     
    Amar Saikia
    Ranch Hand
    Posts: 43
    2
    • Likes 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    IMHO, Your naming should be such that you don't have to write a comment for the name to describe what it will do. By that principle, your 1st set of naming looks better, considering that you will get rid of the comments. The main purpose of better naming is no make our code clean and readable. The comments in your code looks redundant. You can refer the book "Clean Code" by Robert C Martin to know more about clean code.
     
    Campbell Ritchie
    Marshal
    Posts: 56533
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Why are you using floats? you should not use floating‑point arithmetic for money because of imprecision, and using floats makes the imprecision even worse.

    You can see what you should use for money calculations here. There is more useful information near the end of the thread.
     
    Bartholomew Benson
    Greenhorn
    Posts: 19
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Money? Actually, the goal of this code is to make a simple sprite animator by modifying an index to an array of sprites over time, where the rate of change of the index value is linearly dependent upon speed. Later, the index value is floored to obtain the 'current' sprite. I'm not sure if the way I'm going about it is the simplest or best way to do it, but it seems to work well enough for me.

    As for the names, I guess I could make them a little shorter while still being as descriptive as a really long name. Actually, initially, the fields didn't have comments on them; I added those later to describe what they were about. I'll also try to avoid describing what the variables do and focus more on the data itself.
     
    Campbell Ritchie
    Marshal
    Posts: 56533
    172
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You have to pay sprites, surely?

    You're doing well to correct me
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!