7

I declare some constant variables in my SQLiteOpenHelper class:

public static final String USERNAME = "user_name";
public static final String PASSWORD = "password";

In an Activity where I create SQL queries, I import these fields:

import com.mygame.ui.login.LoginInfoSQLiteOpenHelper.*;

Is this a good practice?
Or the traditional way of referring to constants better?

LoginInfoSQLiteOpen.USERNAME
c00kiemon5ter
  • 16,994
  • 7
  • 46
  • 48
linisax
  • 151
  • 4
  • 6

3 Answers3

10

If you look at someone's code and see a field like

foo.do(baz, USERNAME);

wut(!), where did that var come from ?
search, grep, where is it declared ?

Using it as ClassName.FIELD makes things much clearer and cleaner. You avoid confusion, and sometimes it makes more sense to have a proper classname that denotes the field, than a field that came out of nowhere.

well, not everyone uses an IDE, and not everyone reads code through an IDE(maybe through a repository on the web), and even some consider VIM an IDE, and I do use vim a lot(although I don't think of it as an IDE).
So, it's not about what an IDE can or can't do, but more of what code reading is about. Code reading, code quality, expressing ideas in your programming language of choice, in a way through abstractions that make sense and tie well together.

c00kiemon5ter
  • 16,994
  • 7
  • 46
  • 48
  • What, your IDE doesn't show you what USERNAME is and where it came from? ;-) [I do like this answer -- in general -- though.] –  Jun 28 '11 at 02:06
  • 1
    As an aside, it's generally considered bad practice to use `import package.*`. Better to replace it with explicit `import package.SomeClass` statements. – Cameron Skinner Jun 28 '11 at 02:27
  • 1
    I second that, and that's again a code reading issue, not at all related to any kind of permormance issues, as some tend to think. – c00kiemon5ter Jun 28 '11 at 02:32
  • 1
    Although I agree in general, I have one exception to this which is the usage of assertXX() in JUnit tests. That is only because of the specific context in which they are used. – Robin Jun 28 '11 at 02:48
  • @ Ivan c00kiemon5ter V Kanak : Thanks for the input. This clears out the doubts for me. It is always good to know the right and good programming approach that makes our code cleaner and readable. – linisax Jun 28 '11 at 17:10
  • -1, in my opinion unless you need lots of different static imports, having to write the full class and/or package everytime worsen code readability. – Yuri Ghensev Mar 27 '12 at 23:02
4

A few years late to the party... but I feel it is worth providing the opposite point of view. There is a reason why Java was designed to have static field imports, and the reason is to hide how the class is implemented to users of the class. This is an important design principle for outwardly facing code. I would agree with c00kiemon5ter take on it, however, there might be situations in which it is worthwhile.

More info on static field importing can be found here: https://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html

TolkienWASP
  • 309
  • 1
  • 3
  • 10
3

I recommend the second method, only importing classes not fields. So prefixing your constants with the owning class, like LoginInfoSQLiteOpen.USERNAME. It can become highly redundant, but it is much more readable and maintainable in the long run.

Courtney Christensen
  • 9,165
  • 5
  • 47
  • 56