I'm not here, but I noticed your query, which is the sort of thing that will occur repeatedly. Searh my posts for keyboard input utility class; you probably will only find parts of the utility class but beware: one of my old posts has a serious mistake in. I don't thnk you should clean up that line at all. Write a utility class containing these two overloaded nextInt(...) methods:-Call it like this:-
posted 1 month ago
Carey? why should you avoid numbers? is it just for scalability down the line? i see what you doing here, very nice. but in this context what difference does it make?
Campbell, thanks for that,you are answering my other post on utility class? thanks I will study that code
wayne brandon wrote:Carey? why should you avoid numbers? is it just for scalability down the line? i see what you doing here, very nice. but in this context what difference does it make?
I don't know what your context is, only your snippet. In general, magic numbers by themselves don't convey their meaning. Making them constants gives them a name and improves readability. It also helps when you want to change MAX_PLAYER to 6. This will avoid having to find all occurrences of 4 and change them to 6, hoping that you don't change a 4 that is serving some other purpose than to indicate maximum number of players. In your, presumably, small program this may not be necessary, but it's a good habit to get into.
wayne brandon wrote:. . . why should you avoid numbers? . . .
Try writing magic numbers without explanation and come back in twelve months and remember what those numbers mean.
When 12 might be MONTHS_IN_YEAR or EGGS_IN_BOX or TRIBES_OF_ISRAEL, try porting your app to somewhere with a lunar calendar, where there are 13 MONTHS_IN_YEAR. Now try to remember which 12s need changing to 13s.
Campbell . . . you are answering my other post on utility class? . . .
Martin Fowler wrote:Any fool can write code a computer can understand; good programmers write code that humans can understand.
Maintenance makes up the bulk of the overall cost of software. If your code is not maintainable because it is cryptic and difficult to understand, then it becomes more costly. Even if there is no monetary value involved, it still costs someone time and effort. So if you want to be a good programmer, strive to write code that is easy to understand and work with.
Make your code express its intent clearly. Replace formulas like what you have with a call to a method with an intention revealing name.
A common example is this:
The former gives a formula that needs to be deciphered by the reader. The latter reveals the intent of the formula.